http://www.slony.info/bugzilla/show_bug.cgi?id=128

--- Comment #8 from Steve Singer <ssinger at ca.afilias.info> 2010-09-03 08:31:54 PDT ---
With the patch applied consider this sequence of events:

1) have a replication with table "a" running between node 1 and node 2.
2) stop all slons
3) pg_dump node 2.  
4) drop the database on node 2. 
5) create a new database on node to and restore the pg_dump (say your upgrading
postgres versions on this node or something
6) make sure that you do NOT run 'REPAIR CONFIG' because you've forgotten to
7) Do the MOVE SET from node 1 => node 2 

With the patch applied the move set will 'appear' to work and log the NOTICE. 
However it leaves you in a state where both node 1 and node 2 have the _deny
trigger enabled on them.

I'm thinking that if a row in pg_class with that oid is NOT found then we want
to check to see if a table by that name can be found.  If the OID doesn't match
but a table of the same name exists then we maybe want to raise an exception
(like we do without the patch) so the DBA can run a 'REPAIR CONFIG' to fix
things.

If both the oid and tablename can't be found in pg_class then we can just raise
the notice.

OR  we could leave alterTableXXXXTriggers() as is and make REPAIR CONFIG remove
the rows from sl_table if it can't match by oid or by name.   slonik connects
directly to the EVENT_NODE and can run a repair config so we can skip-ahead of
the failing moveSet' in the event queue.

Thoughts?

-- 
Configure bugmail: http://www.slony.info/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.