On 09/01/2017 02:29 AM, Peter J. Holzer wrote:
TLDR: Don't.
I'm currently conducting tests which should eventually lead to a 2 node
cluster with working bidirectional logical replication.
(Postgresql 9.6.4-1.pgdg90+1, pglogical 2.0.1-1.jessie+1 on Debian 9
(Stretch))
pglogical supports replication of sequences, and although the way it
does this suggests that it can't really work in both directions
(actually I'm sceptical that it works reliably in one direction), of
course I had to try it.
So I created a sequence on both nodes and called
select pglogical.replication_set_add_sequence('default', 'test_sequence');
on both nodes.
The result was ... interesting.
First I got the same sequence (1, 2, 3, 4, 5) on both nodes.
After a few seconds the replication kicked in, and then I got the same
value (1005) on both nodes most of the time, with a few variants (2005,
3005) thrown in.
In a word, the sequence was completely unusable.
Experiment completed, so I removed the sequence from the replication
set:
select pglogical.replication_set_remove_sequence('default', 'test_sequence');
on both nodes.
But the behaviour of the sequence doesn't change. It still returns 1005
most of the time, and sometimes 2005 or 3005. This is true even after
restarting both nodes.
Plus, I can't drop the sequence any more (as the user who created the
sequence):
wds=> drop sequence public.test_sequence ;
ERROR: permission denied for schema pglogical
So, clearly, pglogical is still managing that sequence.
If I drop the sequence as postgres and then recreate it, it works
normally for some time (also the sequence on the other node now works
normally), but after some time, the replication kicks in again and the
sequence is stuck again at 1005.
So, is there a way to recover from this situation without drastic
measures like nuking the whole database.
hp
I trust you mean don't use sequences
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
