alvherre@alvh.no-ip.org (Alvaro Herrera) writes:
> On Tue, Aug 30, 2005 at 12:45:18PM -0400, Chris Browne wrote:
>> dparker@tazznetworks.com ("David Parker") writes:
>> > The slony log trigger saves execution plans, so any given
>> > connection that has been used with a slony schema installed will
>> > have cached OIDs referring to the sl_log_1 table. When you drop
>> > the schema, those OIDs obviously go away. When you re-create the
>> > schema, and try to use the old connection, it still has the old
>> > plan cached in it, so the OIDs in the plan are out of sync with
>> > what actually exists in the database.
>> >
>> > This is the behavior I've observed in our environment,
>> > anyway. The problem always shows up when slony is RE-installed
>> > under an outstanding connection.
>>
>> I have observed much the same behaviour...
>>
>> It would be really useful to have some guidance as to how to
>> resolve this.
>>
>> What is needed is to invalidate the cached execution plans.
>
> The simplest way to do that is to disconnect the client, and start a
> fresh session.

I'm keen on a "simplest way" that doesn't essentially involve having
to restart the application...

>> Unfortunately, it's not at all obvious how to accomplish that :-(.
>
> I don't think it can be easily done with the current code. This is
> plpgsql code, right? There are some ways to cause recompilation for
> those, at least on the 8.1 code I'm looking at.

No, the troublesome parts are in C/SPI code.

If it's something Neil Conway hasn't quite figured out how to handle
yet, I don't feel so bad that I can't imagine a way to do it... :-)
--
select 'cbbrowne' || '@' || 'acm.org';
http://cbbrowne.com/info/spiritual.html
A cool feature of OOP is that the simplest examples are 500 lines.
-- Peter Sestoft