On Mon, Jun 23, 2008 at 05:29:47PM +0200, Cyril SCETBON wrote:
> >
> >There's no way for Slony to know this.  I agree it would be nice, but it's
> >simply impossible.  This is a consequence of the way MVCC in Postgres 
> >works.
> >  
> I was thinking that simply looking at pg_locks (known for hurting 
> performance) would help.

No.

Suppose T1 starts, and then sits there for a while.  It will be in pg_locks
(because every transaction has one entry), but you don't know what tables
it's going to touch by looking at that view.

Now, Slony comes along and wants to dump the database in a consistent way,
because it is setting up.  This is the consistent starting point _before
which_ Slony knows it can ignore transactions (because remember, when you
set up replication on a table, you created the triggers; but Slony has to
know what the starting point is in that list of transactions for any given
replica).  All that Slony can know, then, is whether there are transactions
prior to itself outstanding.  If the answer is yes, Slony has to wait until
those transactions commit, so it can be sure that nothing will happen that
(1) the dump can't see and (2) will never be included in any data sent to
the target replica.

That's sort of oversimplifying it, but it's the basic problem.

A