In response to Dane Miller <dane at greatschools.net>:

> 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/

wmoran at collaborativefusion.com
Phone: 412-422-3463x4023