I'm afraid that's not the issue here; or there's a deeper conflict  
that I'm not understanding.

To test your hypothesis that there was a trigger name conflict here,  
I tried to add a new constraint on another table called calendar via  
DDL scripts, which has no other triggers besides the slony triggers.

Before I ran the DDL script, I checked pg_trigger:

select tgname from pg_trigger where tgrelid in (select oid from pg_class
where relname in ('calendar'));

On all nodes, there was only one trigger:

on the master node, the trigger was named  
_tmc_replication_logtrigger_26;
on the slave nodes, the trigger was named _tmc_replication_denyaccess_26

the DDL Script fed to slonik was as follows:

#!/bin/sh

#
# Create a new constraint in the calendar table
#
echo "Changing schema"
slonik <<_EOF_
cluster name = tmc_replication;
node 1 admin conninfo='host=dbmaster1 dbname=tmc user=postgres  
port=5432';
node 2 admin conninfo='host=dbstage1 dbname=tmc user=postgres  
port=5432';
node 3 admin conninfo='host=dbtest1 dbname=tmc user=postgres port=5432';
execute script ( SET ID = 1, FILENAME = 'testChanges.sql', EVENT NODE  
= 1);
_EOF_

And the sql script read as follows:
alter table calendar add constraint good_dow check (extract(dow from  
dte) not in (0,6));

The change failed; with the following entry on the slave nodes:

#-------
begin transaction;
set transaction isolation level serializable;
lock table "_tmc_replication".sl_config_lock;
select "_tmc_replication".ddlScript_int(1, 'alter table calendar add  
constraint good_dow check (extract(dow from dte) not in (0,6));', -1);
notify "_tmc_replication_Event";
notify "_tmc_replication_Confirm";
insert into "_tmc_replication".sl_event
(ev_origin, ev_seqno, ev_timestamp,
ev_minxid, ev_maxxid, ev_xip, ev_type ,
ev_data1, ev_data2, ev_data3    ) values
('1', '379813', '2006-06-29 09:59:23.921595',
  '89693770', '89693771', '', 'DDL_SCRIPT', '1',
'alter table calendar add constraint good_dow check (extract(dow from  
dte) not in (0,6));
', '-1');
insert into "_tmc_replication".sl_confirm
(con_origin, con_received, con_seqno, con_timestamp)    values
(1, 2, '379813', now());
commit transaction;
PGRES_FATAL_ERROR ERROR:  duplicate key violates unique constraint  
"pg_trigger_tgrelid_tgname_index
CONTEXT:  SQL statement "update "pg_catalog".pg_trigger set tgrelid  
=  $1  where tgrelid =  $2
PL/pgSQL function "altertablerestore" line 68 at SQL statement
SQL statement "SELECT  "_tmc_replication".alterTableRestore( $1 )"
#------


Could the index be corrupt? Any suggestions of what to do here?  
Thanks for any help.


On Jun 28, 2006, at 6:09 PM, Christopher Browne wrote:

> Cutting it down to the most vital bit, the question is why uniqueness
> of  the index is getting violated.
>
> bz at localhost:5832=# \d pg_trigger_tgrelid_tgname_index
> Index "pg_catalog.pg_trigger_tgrelid_tgname_index"
>  Column  | Type
> ---------+------
>  tgrelid | oid
>  tgname  | name
> unique, btree, for table "pg_catalog.pg_trigger"
>
> Apparently there is already a trigger with the same name against  
> the table.
>
> Take a look at the contents of pg_trigger thus, on master and the
> failing subscriber:
>
> select * from pg_trigger where tgrelid in (select oid from pg_class
> where relname in 'exchange_info', 'locale');
>
> I expect you'll discover that the subscriber already had a  
> trigger.  How
> it got there is the puzzle you'll need to figure out, and that'll
> hopefully explain why it broke.  Actually, it's probably useful to
> compare several nodes; master, a "slave where it worked," and "slave
> where it broke."


######################################################################
This e-mail is confidential and should not be redistributed or
forwarded by the recipient.  The information contained in this e-mail
message is intended only for the use of the individual or entity named
above.  If the reader of this message is not the intended recipient or
you have received this communication in error, please immediately
notify us by telephone.  Receipt by anyone other than the intended
recipient is not a waiver of any work-product or, if applicable,
attorney-client privilege.

This e-mail does not constitute an offering of any security.  Such an
offering may only be made by means of a private placement memorandum
or other disclosure document.  Nothing in this e-mail constitutes
investment advice.  Past performance is not indicative of future
results.  All e-mail to and from Millburn Ridgefield Corporation and
its affiliates is monitored, stored and made available to regulators
if requested.
######################################################################