"Jaime Casanova" <jcasanov at systemguards.com.ec> writes:
> On Mon, Jul 28, 2008 at 1:21 PM, chris <cbbrowne at ca.afilias.info> wrote:
>> "Jaime Casanova" <jcasanov at systemguards.com.ec> writes:
>>> Is the example in this page
>>> (http://lists.slony.info/documentation/stmtmergeset.html) right? it
>>> seems not to me...
>>> or am i missing something?
>>
>> Nothing is leaping out at me as being wrong.
>>
>> What do you think is wrong about it?
>
>
> -- CODE MODE ON --
>      # Assuming that set 1 has direct subscribers 2 and 3
>      SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 2);
>      SYNC (ID=1);
>      WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 2, WAIT FOR=1);
>      SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 3);
>      SYNC (ID=1);
>      WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 3, WAIT FOR=1);
>      MERGE SET ( ID = 1, ADD ID = 999, ORIGIN = 1 );
> -- CODE MODE OFF --
>
> first WAIT FOR, shouldn't be WAIT ON?

Ah, yes.  Because "FOR" and "ON" are both reasonable looking words in
that context, that wasn't visible.

That change *is* in place in HEAD; someone already pointed it out; we
just didn't have a copy put online with the fix.

> second, what's the idea of merging the same set (ID=999)? is the
> idea of this example a merge between nodes?

No, the idea is that you have some new tables you want subscribed; you
set up the new set, #999, get it subscribed everywhere, and then merge
it into set #1, getting rid of set #999.

There are two SUBSCRIBE SET requests on set #999 because, as is stated
in the assumptions, set #1 has direct subscribers 2 and 3.  Set #999
must have identical subscription paths as Set #1 in order to be able
to merge the sets.
-- 
select 'cbbrowne' || '@' || 'linuxfinances.info';
http://cbbrowne.com/info/lsf.html
Rules  of the  Evil Overlord  #145. "My  dungeon cell  decor  will not
feature exposed pipes.  While they add to the  gloomy atmosphere, they
are good  conductors of vibrations and  a lot of  prisoners know Morse
code." <http://www.eviloverlord.com/>