alvherre(at)alvh(dot)no-ip(dot)org (Alvaro Herrera) writes:
> On Tue, Aug 30, 2005 at 12:45:18PM -0400, Chris Browne wrote:
>> dparker(at)tazznetworks(dot)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';
A cool feature of OOP is that the simplest examples are 500 lines.
-- Peter Sestoft
In response to
pgsql-hackers by date
|Next:||From: Jeff MacDonald||Date: 2005-08-30 22:12:21|
|Subject: Re: problems installing pgsql on rh9 box|
|Previous:||From: Andreas Pflug||Date: 2005-08-30 21:36:13|
|Subject: Re: [Slony1-general] Re: dangling lock information?|