Re: another failover testing question

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 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 are still fine
5) re-configure replication (re-creates sl_log_1 table)
6) now the OID error appears in the client connection. The OID refers
to the previous version of the sl_log_1 table

I was pawing through our code to figure out where we might be saving a
prepared statement, and was forgetting that the slony1_funcs library
does this. This saved plan is executed with SPI_execp, and the
documentation states:

"If one of the objects (a table, function, etc.) referenced by the
prepared plan is dropped during the session then the results of
SPI_execp for this plan will be unpredictable."

I'm pretty sure I understand the problem now (corrections appreciated),
but I'm left with the operational question of how I get around this
issue. Is there any way short of PQreset to get a postgres process to
refresh its saved plans? I can generally avoid the
drop-replication/re-configure replication thing happening in our
procedures, but I can't prevent it completely....

- DAP

>> 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 start getting the OID error.
>> If this should indeed not be an issue in 7.4.5, I will try
>to come up
>> with a test case independent of a slony install.
>
>It should not be ... at least, assuming that Slony is using
>the standard DROP TRIGGER operation, rather than playing
>directly with the system catalogs ...
>
>            regards, tom lane
>