Re: another failover testing question
От | David Parker |
---|---|
Тема | Re: another failover testing question |
Дата | |
Msg-id | 07FDEE0ED7455A48AC42AC2070EDFF7C74684C@corpsrv2.tazznetworks.com обсуждение исходный текст |
Ответ на | another failover testing question ("David Parker" <dparker@tazznetworks.com>) |
Список | pgsql-general |
>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
В списке pgsql-general по дате отправления: