On Wed, May 26, 2010 at 4:11 PM, Dimitri Fontaine <dfonta...@hi-media.com> wrote: > Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: >> Perhaps I'm missing something, but I thought that Slony currently uses a >> heartbeat, and all transactions committed between two beats are banged >> together and committed as one in the slave so that their relative commit >> order doesn't matter. > > I guess Slony does the same as pgq here: all events of all those > transactions between two given ticks are batched together in the order > of the event commits. (In fact the batches are made at the consumer > request, so possibly spreading more than 2 ticks at a time). > > If you skip that event ordering (within transactions), you can't > maintain foreign keys on the slaves, among other things. > > The idea of this proposal is to be able to get this commit order > directly from where the information is maintained, rather than use some > sort of user sequence for that.
Exactly. > So even ordering the txid and txid_snapshots with respect to WAL commit > time (LSN) won't be the whole story, for any given transaction > containing more than one event we also need to have them in order. I > know Jan didn't forget about it so it must either be in the proposal or > easily derived, too tired to recheck. Right, so the point is - with this proposal, he can switch to using a LOCAL sequence number to order events within the session and then order the sessions using the commit ordering. Right now, he has to use a GLOBAL sequence number because there's no way to know the commit order. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
