Slony1 PostgreSQL Replication - Sequence replication

Author

Sequence replication

Jim Archer

2005-09-06, 8:24 pm

Hi All...

Over the weekend, I was playing with Slony. I noticed that if I try to
modify a data table on a slave node I get an error, which is good. I als=
o
noticed, however, that I can call nextval() against a sequence and get th=
e
next value.

Afte doing this I added a record to the master, which populated a column
with the next sequence value, and the record replicated with the value
from the master.

I am guessing when I reconfigure the cluster do the slave becomes the
origin that the sequence will pick up at its value after my call to
nextval(), but I am also thinking this is harmless, unless there is an
issue with my code. Is this all correct?

Christopher Browne

2005-09-06, 8:24 pm

Jim Archer wrote:

>Hi All...
>
>Over the weekend, I was playing with Slony. I noticed that if I try to
>modify a data table on a slave node I get an error, which is good. I also
>noticed, however, that I can call nextval() against a sequence and get the
>next value.
>
>Afte doing this I added a record to the master, which populated a column
>with the next sequence value, and the record replicated with the value
>from the master.
>
>I am guessing when I reconfigure the cluster do the slave becomes the
>origin that the sequence will pick up at its value after my call to
>nextval(), but I am also thinking this is harmless, unless there is an
>issue with my code. Is this all correct?
>
>
What you'll see on a subscriber node is that the current value of the
sequence will be regularly reset to the then-present value on the origin
node.

I suppose that if you ran nextval()/setval() on the subscriber at the
wrong time, you could "muss things up" somewhat by forcing a value
inconsistent with what you had elsewhere.

But as long as you've not got processes that are cavalier about updating
sequences, the subscriber should often enough get reset to the state on
the origin, and when the origin shifts to the subscriber, the subscriber
can be expected to have the right value for the sequence to pick up and
move on...

It's probably always possible to shoot yourself in the foot; keep those
misplaced nextval()s to a "dull roar" and you should be OK :-).

Jim Archer

2005-09-06, 8:24 pm

Christopher Browne said:

> What you'll see on a subscriber node is that the current value of the
> sequence will be regularly reset to the then-present value on the origi=
n
> node.

Ah, okay, so much the better.

> It's probably always possible to shoot yourself in the foot; keep those
> misplaced nextval()s to a "dull roar" and you should be OK :-).

I have no plans to allow code to modify any subscribed database. I
realize there is no good to come from that. I was curious what would
happen though. I did read the design doc, and I saw it discussed sequenc=
e
replication, but I was still unclear, so thanks for letting me know.

I have to say, you guys did a fine job with Slony. This is one of the
coolest things I have worked with in quite a while. Other things are
going by the wayside ;)

Thanks for your help and thanks for Slony!

Sponsored Links