In response to Dane Miller <[EMAIL PROTECTED]>: > Andrew Sullivan wrote: > > Dane Miller wrote: > > > Consider the below example. Does Slony guarantee that the updated > > > sequence will always appear after (or concurrently with) the result > > > of the I/U/D statements on subscriber nodes? > > > > Not necessarily. Slony sets the sequence on the target to the value > > of the sequence at the time of the sync, because there isn't any other > > way to look at the sequence value. The idea is that it's ok for a > > sequence to be _ahead_ of the rest of the database, because this is > > consistent with the semantics of sequences in an unreplicated database > > (they always advance, so they're never-go-backwards series that > > possibly have gaps). > > > > If you want this, you could probably do it using a table that is > > replicated and that gets updated with currval() using a trigger or > > something. > > Thanks very much Andrew. I think this explains errors we are seeing on > supposedly up-to-date subscriber nodes. > > I think storing currval() in a table, as you suggest, looks promising... > perhaps using TRUNCATE before each insert to avoid dead tuple bloat.
Don't TRUNCATE a replicated table. It will ruin replication. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 _______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
