Norman Yamada wrote:
> Yes, it isn't a name problem then. On our two slave nodes:
>
> tmc=# select tgrelid, tgname,count(*) from pg_trigger group by 1,2
> having count(*) > 1;
> tgrelid | tgname | count
> ---------+--------+-------
> (0 rows)
>
> So are you saying that EXECUTE SCRIPT would disable triggers even on
> tables in different schemas? 
No, it would just disable the triggers where tgrelid matches the OID of
one of the replicated tables.
> In any case, assuming that your hypothesis is correct, how do we fix
> this now? (I'd like to be able to run execute script on my slony
> tables sometimes ; ) )
Oh, I was trying to avoid thinking about that :-), in favor of thinking
about the long term answer.

Short term is a bit troublesome.

There's *sort of* a way to live with the issue...

- You let there be two copies of the trigger, normally.  One hidden, one
visible.

- Upon submitting EXECUTE SCRIPT, events will start failing because of
the 2nd trigger copy.

- At that point, submit a DROP TRIGGER against the subscriber, which
will drop out the extra trigger, and allow the DDL to run.

- Now comes the touchy part; you probably want the trigger back.  I
suppose you add it directly against the subscriber, after the DDL has run.

- The touchy thing about it is that there may be some gap of time
between when EXECUTE SCRIPT finished and when you got the trigger back
in place, during which there was no trigger running on the table.

- The extension to EXECUTE SCRIPT would be for it to be aware that the
trigger shouldn't ever ever get hidden.  That shouldn't be overly
tricky; it just needs attention to detail.  It may not even be a large
change in functionality to Slony-I...