>It should not be ... at least, assuming that Slony is using
>the standard DROP TRIGGER operation, rather than playing
>directly with the system catalogs ...
AFAICS, the slony uninstall command is not doing anything exotic, though
it DOES do a little bit of fiddling with pg_catalog to RESTORE
previously disabled triggers. Otherwise it is using plain vanilla drop
trigger.
I found a slony list thread from a few months ago that discussed this
issue: http://archives.postgresql.org/pgsql-general/2005-02/msg00813.php
The discussion there centered around cached plans causing the "no
relation with OID" problem. The area of our code that experiences these
problems is calling libpq - we have a wrapper for it that plugs into our
Tcl environment - but it is not using prepared statements, and the
commands it is executing are not calls to stored procedures, etc.
I cannot repro this problem simply using psql, so it must have something
to do with the way we are using libpq, but I have no idea what object(s)
we are holding onto that reference slony OIDs.
- DAP
