"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
[GENERAL] another failover testing question
>
>"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
"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
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 of "OID
123 not found" errors, where the OID
