On Tue, Sep 25, 2007 at 10:33:46AM -0400, Jan Wieck wrote:
> On 9/25/2007 4:21 AM, Marko Kreen wrote:
> >On 9/22/07, Decibel! <decibel at decibel.org> wrote:
> >>Actually, what I'm really wondering is if a "commit ID" analogous to a
> >>transaction ID but set at commit time (and in order of commits) would
> >>vastly simplify things...
> >
> >Could you clarify?  I don't get it.  Assuming we keep the trigger
> >based event logging, the event storage happens at the time of
> >insert/update/delete statement, how can anything determined at
> >commit time be useful?
> 
> I think his theory is about a replication protocol that applies changes 
> on slaves in the commit order of the master. Using such protocol would 
> certainly simplify things, since all the slave has to do is to remember 
> the last commit ID applied, then select all changes with a higher commit 
> ID next time.
> 
> The flaw in that theory is that such protocol would assume an index over 
> the commit ID. Without that index, the entire log would have to be 
> sequentially scanned and sorted each round, so there would not be any 
> benefit to that. But such index cannot be maintained easily because the 
> commit ID isn't known at insert time, so the tuples would have to be 
> revisited after the transaction committed.

Yes, my vision was to have a separate table that tracked what a
transaction's commit ID was; it wouldn't make any sense to go screwing
around in the log table once you got the CID. While not as easy as if
you could just grab a range of XIDs out of the log, it'd still be much
simpler than how syncs currently work.

Another thought occurs to me... I know that folks have asked for commit
triggers in the past for other purposes; if we had that it would be easy
to build your own commit ID with a sequence.
-- 
Decibel!, aka Jim C. Nasby, Database Architect  decibel at decibel.org 
Give your computer some brain candy! www.distributed.net Team #1828
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.slony.info/pipermail/slony1-hackers/attachments/20070925/11c5eed0/attachment.pgp