>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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
