On 9/17/2004 11:18 AM, Christopher Browne wrote:
> hannu at skype.net writes:
>> Is it true (as I think it is) that running pg_dump on master database will
>> stall replication ?
>>
>> If the reason is long-held transaction, could we do something about it,
>> like trying to run pg_dump in some kind of read-only mode ?
> 
> It will halt things iff the pg_dump includes the Slony-I cluster
> schema, because the 'generate Sync' event that Slony-I periodically
> raises does an explicit
>   "LOCK _slonyschema.sl_event;"

I have changed that in REL_1_0_STABLE and HEAD to a LOCK ... IN 
EXCLUSIVE MODE. The purpose of that lock table is to guarantee that all 
events get sequence numbers assigned in the events commit order. For 
that it is absolutely sufficient to serialize all inserting transactions 
before they have a chance to call nextval(). When writing that code I 
was not aware that LOCK TABLE defaults to ACCESS EXLUSIVE MODE.

> 
> That winds up waiting for the pg_dump to finish, and all the other
> Slony-I work that is trying to access sl_event sits and waits behind
> that.
> 
> You can evade the problem if you can pg_dump just the schemas that you
> need, and avoid pg_dump'ing the Slony-I cluster schema.  We've been
> able to make use of that evasion.

I guess this is time now for a 1.0.3 release.

> There will doubtless be some discussions as to whether the lock could
> be a little less intrusive; it's not self-evident whether the present
> policy is forcibly necessary, or if some less exclusive lock could be
> sufficient.

The now added comment about the purpose of the lock would have made 
things clear.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #