From: | "David Parker" <dparker(at)tazznetworks(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "postgres general" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: another failover testing question |
Date: | 2005-05-27 13:37:25 |
Message-ID: | 07FDEE0ED7455A48AC42AC2070EDFF7C74684C@corpsrv2.tazznetworks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2005-05-27 13:56:33 | Re: Trigger and arguments question |
Previous Message | Hervé Inisan | 2005-05-27 11:53:02 | Re: Trigger and arguments question |