Initial subscription blocks with "sequence ID <xxx> has already been assigned"

[Stuart Bishop]

If the database connection to the master database is killed during a
subscription operation, an ERROR will be logged:

2008-10-24 17:49:49 BST ERROR remoteWorkerThread_1: "select
"_sl".tableHasSerialKey('"public"."translationrelicensingagreement"');"
2008-10-24 17:49:49 BST WARN remoteWorkerThread_1: data copy for set 1 failed
- sleep 15 seconds

remoteWorkerThread doesn't want to give up however:

2008-10-24 17:52:35 BST DEBUG1 copy_set 1
2008-10-24 17:52:35 BST DEBUG1 remoteWorkerThread_1: connected to provider DB
2008-10-24 17:52:35 BST DEBUG2 remoteWorkerThread_1: prepare to copy table
"public"."announcement"

Eventually it will fail again, and continue to do so until the subscription
stopped and the cluster repaired:

2008-10-24 21:24:25 BST DEBUG2 remoteWorkerThread_1: all tables for set 1 found
on subscriber
2008-10-24 21:24:25 BST DEBUG2 remoteWorkerThread_1: copy sequence
"public"."ann
ouncement_id_seq"
2008-10-24 21:24:25 BST ERROR remoteWorkerThread_1: "select
"_sl".setAddSequence_int(1, 200, '"public"."announcement_id_seq"',
'public.announcement_id_seq')" PGRES_FATAL_ERROR ERROR: Slony-I:
setAddSequence_int(): sequence ID 200 has already been assigned
2008-10-24 21:24:25 BST WARN remoteWorkerThread_1: data copy for set 1 failed
- sleep 60 seconds

[James (james-demichele)]

Yeah I am seeing the exact same error, and every single table and sequence has a unique ID assigned to it.

Is there any work around for this?

I've tried completely stripping the master of the _stingray_cluster schema, and am starting from scratch with my slave. This seems to be a new issue for me, since i've set up a lot of slaves before.

The same thing keeps happening though. Any ideas?

[James (james-demichele)]

Is it possible that once you hit 200, that it can't figure out how to put any more sequences on? My issue doesn't seem to correspond to any connection issues, but it might be happening right around that 200 threshold.

[Stuart Bishop (stub)]

@James - 200 is the first sequence id in that replication set. What was triggering the connection to die was running out of disk space. You might have a similar fatal error occurring that triggers this behavior.