Log Message:
-----------
Trigger unhiding change - look for cases where there will be a conflict
between hidden triggers and those that are on Slony-I-replicated tables,
and generate an exception.

This should be less mystifying than the present situation where the
subsequent query, to update pg_trigger, fails with a "not-unique" complaint
about the PK index on pg_trigger.

Also added an FAQ entry to document what you might do if this happens...

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        faq.sgml (r1.58 -> r1.59)
    slony1-engine/src/backend:
        slony1_funcs.sql (r1.86 -> r1.87)

-------------- next part --------------
Index: faq.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/faq.sgml,v
retrieving revision 1.58
retrieving revision 1.59
diff -Ldoc/adminguide/faq.sgml -Ldoc/adminguide/faq.sgml -u -w -r1.58 -r1.59
--- doc/adminguide/faq.sgml
+++ doc/adminguide/faq.sgml
@@ -1777,6 +1777,57 @@
 </answer>
 </qandaentry>
 
+<qandaentry> <question> <para> I was trying to request <xref
+linkend="stmtddlscript"> or <xref linkend="stmtmoveset">, and found
+messages as follows on one of the subscribers:</para>
+
+<screen>
+NOTICE: Slony-I: multiple instances of trigger defrazzle on table frobozz
+NOTICE: Slony-I: multiple instances of trigger derez on table tron
+ERROR: Slony-I: Unable to disable triggers
+</screen>
+</question>
+
+<answer> <para> The trouble would seem to be that you have added
+triggers on tables whose names conflict with triggers that were hidden
+by &slony1;. </para>
+
+<para> &slony1; hides triggers (save for those <quote>unhidden</quote>
+via <xref linkend="stmtstoretrigger">) by repointing them to the
+primary key of the table.  In the case of foreign key triggers, or
+other triggers used to do data validation, it should be quite
+unnecessary to run them on a subscriber, as equivalent triggers should
+have been invoked on the origin node.  In contrast, triggers that do
+some form of <quote>cache invalidation</quote> are ones you might want
+to have run on a subscriber.</para>
+
+<para> The <emphasis>Right Way</emphasis> to handle such triggers is
+normally to use <xref linkend="stmtstoretrigger">, which tells
+&slony1; that a trigger should not get deactivated. </para> </answer>
+
+<answer> <para> But some intrepid DBA might take matters into their
+own hands and install a trigger by hand on a subscriber, and the above
+condition generally has that as the cause.  What to do?  What to do?
+</para>
+
+<para> The answer is normally fairly simple: Drop out the
+<quote>extra</quote> trigger on the subscriber before the event that
+tries to restore them runs.  Ideally, if the DBA is particularly
+intrepid, and aware of this issue, that should take place
+<emphasis>before</emphasis> there is ever a chance for the error
+message to appear.  </para>
+
+<para> If the DBA is not that intrepid, the answer is to connect to
+the offending node and drop the <quote>visible</quote> version of the
+trigger using the <acronym>SQL</acronym> <command>DROP
+TRIGGER</command> command.  That should allow the event to proceed.
+If the event was <xref linkend="stmtddlscript">, then the
+<quote>not-so-intrepid</quote> DBA may need to add the trigger back,
+by hand, or, if they are wise, they should consider activating it
+using <xref linkend="stmtstoretrigger">.</para>
+</answer>
+</qandaentry>
+
 <qandaentry id="neededexecddl">
 
 <question> <para> Behaviour - all the subscriber nodes start to fall
Index: slony1_funcs.sql
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/src/backend/slony1_funcs.sql,v
retrieving revision 1.86
retrieving revision 1.87
diff -Lsrc/backend/slony1_funcs.sql -Lsrc/backend/slony1_funcs.sql -u -w -r1.86 -r1.87
--- src/backend/slony1_funcs.sql
+++ src/backend/slony1_funcs.sql
@@ -3774,6 +3774,8 @@
 	v_tab_fqname		text;
 	v_tab_attkind		text;
 	v_n					int4;
+	v_trec	record;
+	v_tgbad	boolean;
 begin
 	-- ----
 	-- Grab the central configuration lock
@@ -3840,6 +3842,32 @@
 
 
 		-- ----
+		-- Check to see if there are any trigger conflicts...
+		-- ----
+		v_tgbad := ''false'';
+		for v_trec in 
+			select pc.relname, tg1.tgname from
+			"pg_catalog".pg_trigger tg1, 
+			"pg_catalog".pg_trigger tg2,
+			"pg_catalog".pg_class pc,
+			"pg_catalog".pg_index pi,
+			@NAMESPACE at .sl_table tab
+			where 
+			 tg1.tgname = tg2.tgname and        -- Trigger names match
+			 tg1.tgrelid = tab.tab_reloid and   -- trigger 1 is on the table
+			 pi.indexrelid = tg2.tgrelid and    -- trigger 2 is on the index
+			 pi.indrelid = tab.tab_reloid and   -- indexes table is this table
+			 pc.oid = tab.tab_reloid
+                loop
+			raise notice ''Slony-I: multiple instances of trigger % on table %'',
+				v_trec.tgname, v_trec.relname;
+			v_tgbad := ''true'';
+		end loop;
+		if v_tgbad then
+			raise exception ''Slony-I: Unable to disable triggers'';
+		end if;  		
+
+		-- ----
 		-- Disable all existing triggers
 		-- ----
 		update "pg_catalog".pg_trigger