On 2/27/2007 3:53 PM, Jeff Frost wrote: > On Mon, 19 Feb 2007, Jeff Frost wrote: > >> On Fri, 9 Feb 2007, Jan Wieck wrote: >> >>>> >>>> CREATE SET (id = 9998, origin = 1, comment = 'temp set'); >>>> SET ADD TABLE (set id=9998, origin=1, id=15, >>>> FULL QUALIFIED NAME = 'public.test', comment='test table'); >>>> >>>> SUBSCRIBE SET (id=9998, provider=1, receiver=2); >>>> WAIT FOR EVENT (origin=2, confirmed=1, wait on=2); >>>> >>>> SYNC(id = 1); >>>> WAIT FOR EVENT (origin=1, confirmed =2, wait on=1); >>>> >>>> MERGE SET ( id = 1, add id = 9998, origin = 1 ); >>>> ======== >>>> >>>> yah? >>> >>> Nod! >> >> Looks like I still have it slightly off. The following is from a 3 node >> slony cluster with node 3 getting its data from node 2 running slony1-1.2.2: > > I have another one which is simpler, but also did not work. What am I doing > wrong? Naturally, if I go back and try to merge the sets a few seconds > later, > it works great. Here's the error: > > [EMAIL PROTECTED] ~]$ /tmp/v022-012-CreateEmailAddressBook-dev_slony.slonik > /tmp/v022-012-CreateEmailAddressBook-dev_slony.slonik:20: PGRES_FATAL_ERROR > select "_T1".mergeSet(1, 9998); - ERROR: Slony-I: set 9998 has > subscriptions > in progress - cannot merge > > And here's the slonik script. This is with slony1-1.2.6 and postgresql 8.1.8: > > #!/usr/local/slony/bin/slonik > > INCLUDE </home/postgres/lib/preamble-dev_slony.slonik>; > > CREATE SET (id = 9998, origin = 1, comment = 'temp set'); > SET ADD TABLE (set id=9998, origin=1, id=126, > FULL QUALIFIED NAME = 'public.email_address_book', > comment='email_address_book table'); > SET ADD TABLE (set id=9998, origin=1, id=127, > FULL QUALIFIED NAME = 'public.email_address', comment='email_address > table'); > SET ADD TABLE (set id=9998, origin=1, id=128, > FULL QUALIFIED NAME = 'public.email_group', comment='email_group > table'); > SET ADD TABLE (set id=9998, origin=1, id=129, > FULL QUALIFIED NAME = 'public.email_address_group', > comment='email_address_group table'); > > SUBSCRIBE SET (id=9998, provider=1, receiver=2, forward=yes); > WAIT FOR EVENT (origin=2, confirmed =1, wait on=2); > SYNC(id = 1); > WAIT FOR EVENT (origin=1, confirmed =2, wait on=1); > > MERGE SET ( id = 1, add id = 9998, origin = 1 );
This is indeed very odd. When the SUBSCRIBE SET was confirmed by 1, it should have generated the internal ENABLE_SUBSCRIPTION event. The SYNC and WAIT FOR on 1 are the way to make sure that the subscription is indeed complete and that this fact is known on 1. I fail to see how this can result in the above error ... would have to do some testing myself. Jan > > >> >> [EMAIL PROTECTED] ~]$ bin/create_rejected_users.slonik >> DDL script consisting of 2 SQL statements >> DDL Statement 0: (0,118) [CREATE TABLE rejected_users ( >> id bigserial PRIMARY KEY, >> userid BIGINT, >> last_mod_time TIMESTAMP DEFAULT now() >> );] >> bin/create_rejected_users.slonik:5: NOTICE: CREATE TABLE will create >> implicit sequence "rejected_users_id_seq" for serial column >> "rejected_users.id" >> bin/create_rejected_users.slonik:5: NOTICE: CREATE TABLE / PRIMARY KEY will >> create implicit index "rejected_users_pkey" for table "rejected_users" >> DDL Statement 1: (118,199) [ >> >> CREATE INDEX rejected_users_last_mod_time_idx ON >> rejected_users(last_mod_time);] >> Submit DDL Event to subscribers... >> DDL on origin - PGRES_TUPLES_OK >> bin/create_rejected_users.slonik:26: PGRES_FATAL_ERROR select >> "_jefftest_cluster".mergeSet(1, 9998); - ERROR: Slony-I: set 9998 has >> subscriptions in progress - cannot merge >> >> >> and here's the slonik script: >> >> #!/usr/local/slony/bin/slonik >> >> INCLUDE </home/postgres/lib/preamble-jefftest.slonik>; >> >> EXECUTE SCRIPT ( >> SET ID = 1, >> FILENAME = '/home/postgres/sql/create_rejected_users.sql', >> EVENT NODE = 1 >> ); >> >> CREATE SET (id = 9998, origin = 1, comment = 'temp set'); >> >> SET ADD TABLE (set id=9998, origin=1, id=125, >> FULL QUALIFIED NAME = 'public.rejected_users', comment='rejected_users >> table'); >> >> SUBSCRIBE SET (id=9998, provider=1, receiver=2, forward=yes); >> WAIT FOR EVENT (origin=2, confirmed=1, wait on=2); >> SYNC(id = 1); >> WAIT FOR EVENT (origin=1, confirmed=2, wait on=1); >> >> SUBSCRIBE SET (id=9998, provider=2, receiver=3, forward=no); >> WAIT FOR EVENT (origin=3, confirmed=2, wait on=3); >> SYNC(id = 2); >> WAIT FOR EVENT (origin=2, confirmed=3, wait on=2); >> >> MERGE SET ( id = 1, add id = 9998, origin = 1 ); >> >> >> Am I using the wrong ids for wait on? >> >> > -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] # _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
