Andrew,
After considering your answer, and some banging of heads together here,
I think we've resolved this one. Since our use of slony is limited to
database copies between to heartbeat-HA nodes, once the target node is
up to dat we will be switching from the origin to the target. At that
time we will stop any insert processes on the origin, manually copy
(pg_dump probably) the sequences from origin to target, then switch
everything over to the target. Our purpose is to test postgres upgrade
strategies, which this looks like it will work nicely. Thanks for your
help.

Doug

-----Original Message-----
From: slony1-general-bounces at lists.slony.info
[mailto:slony1-general-bounces at lists.slony.info] On Behalf Of Andrew
Sullivan
Sent: Monday, September 22, 2008 11:39 AM
To: slony1-general at lists.slony.info
Subject: Re: [Slony1-general] Recommenation against
sequenceonlyreplication sets

On Mon, Sep 22, 2008 at 10:29:13AM -0400, Knight, Doug wrote:
> Andrew,
> How would you handle a sequence that is accessed by more than one
table?
> We have an audit sequence that is accessed from most of our tables, so
> combining the sequence into a single table set with all accessing
tables
> will make for a very large table set.

Pick one.  It doesn't actually matter -- the sequences are not really
replicated perfectly anyway.  Instead, the sequence is advanced on the
replica to the current value of the sequence at replication time.
This means that the sequences can be logically further ahead on the
replica than on the origin.  This is ok by the semantics of the
sequence, which can be gappy but is not allowed to go backwards.

A

-- 
Andrew Sullivan
ajs at commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/
_______________________________________________
Slony1-general mailing list
Slony1-general at lists.slony.info
http://lists.slony.info/mailman/listinfo/slony1-general