On 11-09-08 06:42 AM, Glyn Astill wrote:
> Hi Guys,
>
> Since we were on slony 1.2 I've been doing full pg_dumps from our
> servers, and restoring them onto a test setup daily.
>
> Since we've moved to 2.0 I've noticed that those full dumps now cause
> the subscribers to lag. I just wanted to ask - is this expected
> behaviour in 2.0? And is the only real workaround skipping the schema
> during pg_dump?

Yes this is expected behaviour.  The only work around is to skip the 
slony schema in pg_dump.


>
> It appears to me that cleanupEvent() is waiting for exclusive access to
> something in the slony schema. An uneducated guess is that it's going to
> be that cleanupEvent() is calling logswitch_start() or
> logswitch_finish() and they are trying to lock sl_config_lock which is
> blocking. In turn cleanupEvent() can't commit some other update it's
> done causing createEvent() to block also?
>
> Am I wrong in thinking cleanupEvent() didn't used to kick off the
> logswitching in 1.2? And am I oversimplifying things by saying why can't
> the logswitch functions just add NOWAIT when trying to lock
> sl_config_lock, and skip it if an exception is raised? Or am I just
> totally wrong?

The issue isn't the cleanup event as much as it is the SYNC event.
When slony generates a SYNC event it gets an exclusive lock on sl_event.
It can't get this exclusive lock if a pg_dump is running that has read 
sl_event.  Changing the cleanupEvent() code won't change this.

Slony 1.2 and 2.0 both behave this way, this shouldn't be new behaviour 
with 2.0.

In Slony 2.1.0 the SYNC event gets the lock on sl_event_lock a table 
that stores no data and is only used for locking.  You could then 
exclude just that table from pg_dump but I don't see a lot of value of 
dumping sl_event anyway.




>
>
> Thanks
> Glyn
>
>
>
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general