Thanks for the information you've both given.

I'm now happy to proceed with adding the sequence using the
   "Create temp set. Add sequence to it. Subscribe all slaves to it.
    Merge with existing set."
scenario.

If any issues crop up, I'll report back.

John

Christopher Browne wrote:
> Andrew Sullivan wrote:
> 
> 
>>On Sat, Jan 07, 2006 at 02:20:53PM +0000, John Sidney-Woollett wrote:
>> 
>>
>>
>>>I need to add a single sequence to an existing replicated set (slony 
>>>1.1.0 and Postgres 7.4.6)
>>>
>>>I remember that it is not advised to have a set with a single sequence 
>>>(although I can't remember why).
>>>   
>>>
>>
>>Because it won't work.  It's some sort of breakage.  I don't recall
>>whether it's been fixed -- IIRC it should be fixable, but I suspect
>>nobody has cared enough to do it.
>> 
>>
> 
> Jan has fixed it in 1.1.5, but that's pending.  Fixes to log shipping
> are mandating RC3, RSN...
> 
> The trouble isn't a *massive* breakage, and, for this use case, probably
> won't be any breakage at all.
> 
> 
>>>1) Create temp set. Add sequence to it. Subscribe all slaves to it. 
>>>Merge with existing set.
>>>   
>>>
>>
>>This will work, except that you should create a dummy table as well. 
>>Then merge the sets, and then use SET DROP TABLE to drop the dummy
>>table.  It's a kludgey workaround, but it does work around without
>>having to rebuild the whole replica from nothing.
>> 
>>
> 
> This is a reasonable workaround, however, it wasn't too likely that John
> was going to run into the problem in the first place.
> 
> The problem with "singleton sequence" comes up only if it turns out that
> the node that is subscribing to this set isn't drawing ANY tables from
> its data source.
> 
> Thus, if you have the two sets:
> 
>  Set 1: tables = { tbl1, tbl2, tbl3 }, sequences = { s1, s2, s3 }
>  Set 2: tables = NULL, sequences = { s4 }
> 
> it actually gets treated, by Slony-I, as the *combination* of these,
> namely...
> 
>  Tables replicated = { tbl1, tbl2, tbl3 }, sequnces = { s1, s2, s3, s4 }
> 
> And that won't cause a problem.
> 
> The problem would come in if you did a MOVE SET on set 1, or somehow,
> otherwise, dropped set #1 out of the picture.
> 
> The condition where replication starts breaking is where you have...
> 
>  Tables replicated = NULL
> 
> It's a pretty abstruse case, which is why it:
> 1.  wasn't noticed as a problem early on
> 2.  wasn't noticed as a possible error condition until about a year
> after Slony-I had gotten first deployed
> 3.  wasn't explained in total detail.  Having a set of "just sequences"
> often *won't* break; explaining when it will break requires getting a
> bit wordy...
> 
> I was discussing it with Brad, today; if memory serves, he's the one
> that first encountered the problem.  The error condition is obscure
> enough that he got a bit confused as to when it does (and doesn't!) break.
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general