> I think I may have found the cause.  It has to do with importing the
> database with a slony schema in it, and dropping that schema, and that
> somehow creating an empty type or something.  I'll investigate more
> tomorrow and let you guys know what i find.
> 
> LOG entry:
> 
> NOTICE:  type "_statistic.xxid" is not yet defined
> DETAIL:  Creating a shell type definition.
> NOTICE:  argument type _statistic.xxid is only a shell
> NOTICE:  type "_statistic.xxid_snapshot" is not yet defined
> DETAIL:  Creating a shell type definition.
> NOTICE:  argument type _statistic.xxid_snapshot is only a shell

hmm, that is interesting, I'm pretty sure that I stripped out all of my
old slony schema before doing dropdb/reload from a completely clean
database archive (that happens to pre-date my use of slony), and still
those log entries show up...

The reason I keep rattling on about deferred triggers is that this error
"could not find trigger 58012131" is generated in only one place: 


postgresql-7.4.7]$ grep -nr 'could not find trigger' .
./src/backend/commands/trigger.c:1835:          elog(ERROR, "could not
find trigger %u", tgoid);


this is in DeferredTriggerExecute(), how it actually reaches that code I
don't know yet given that there aren't any deferrable triggers or
constraints in my database (as you can see):


slave=# select conrelid from pg_constraint where condeferrable = TRUE or
condeferred = TRUE;
 conrelid
----------
(0 rows)

slave=# select tgrelid from pg_trigger where tginitdeferred = TRUE or
tgdeferrable = TRUE;
 tgrelid
---------
(0 rows)

it doesn't seem like this is caused by any direct action on slonys part
but more the result of some side-effect.  It makes me wonder if
disabling triggers by setting their relid to the oid of the table's pk
index is entirely safe...seems to me that it would be more reasonable to
disable them in the normal method and just record the oid of the
triggers disabled in a slony table (or something to that affect).  

... so I've been playing with alterTableForReplication/alterTableRestore
() and it does seem to bear out that when removing the code that
disables triggers, the scripts seem to execute fine on the slave.  There
seem to be a couple of methods to disable triggers, which is the
"correct" method I don't know:

- explicitly set the pg_class.reltriggers count; I've seen this being
used to disable all triggers on a table before but that is about the
extent of it.  It also seems like postgres sets this value itself, my
guess was that when slony adds the new constraint to disable write
access postgres set reltriggers to the count of all the triggers it can
find (haven't confirmed that), though it would explain certain things.

- set pg_triggers.tgenabled to FALSE (and completely ignore
reltriggers)-- a lot of postgres code seems to honor this value though I
haven't been able to find any documentation on it yet that says
explicitly what it is for. :)  Triggers will still show up on the table
since they are still valid but I dont *think* they will execute.

iirc there is also a genuine alter statement in postgres 8 that allows
you to disable a trigger. :)

FWIW.

Cheers,
Matt