"David Parker" <[EMAIL PROTECTED]> writes:
> I can create the missing OID error with:
> 1) configure replication
> 2) establish a client connection, perform operations on replicated
> tables
> 3) remove replication (drops sl_log_1 table)
> 4) operations on replicated tables on client connection ar
I know better what is happening now. I had the scenario slightly wrong.
Slony creates a trigger on all replicated tables that calls into a
shared library. The _Slony_I_logTrigger method in this library
establishes a saved plan for inserts into its transaction log table
sl_log_1. I can create the m
>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
pr
"David Parker" <[EMAIL PROTECTED]> writes:
> Sorry, neglected the version yet again: 7.4.5. What happens is that we
> have active connections accessing tables that are being replicated by
> slony. Then somebody does an uninstall of slony, which removes the slony
> trigger from those tables. Then we
indeed not be an issue in 7.4.5, I will try to come up
with a test case independent of a slony install.
Thanks.
- DAP
>-Original Message-
>From: Tom Lane [mailto:[EMAIL PROTECTED]
>Sent: Thursday, May 26, 2005 4:30 PM
>To: David Parker
>Cc: postgres general
>Subject: Re:
"David Parker" <[EMAIL PROTECTED]> writes:
> Something that we end up doing sometimes in our failover testing is
> removing slony replication from an "active" (data provider) server.
> Because this involves removing triggers from tables, we end up with
> currently connected clients getting a bunch
