Re: [Slony1-general] Re: dangling lock information? - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [Slony1-general] Re: dangling lock information?
Date
Msg-id 20050830181357.GB20513@surnet.cl
Whole thread Raw
In response to Re: [Slony1-general] Re: dangling lock information?  (Chris Browne <cbbrowne@acm.org>)
Responses Re: [Slony1-general] Re: dangling lock information?  (Andreas Pflug <pgadmin@pse-consulting.de>)
List pgsql-hackers
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.

> 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.

-- 
Alvaro Herrera <alvherre[]alvh.no-ip.org>      Architect, www.EnterpriseDB.com
"Si quieres ser creativo, aprende el arte de perder el tiempo"


pgsql-hackers by date:

Previous
From: Ricardo Gamero
Date:
Subject: problems installing pgsql
Next
From: Neil Conway
Date:
Subject: Re: [Slony1-general] Re: dangling lock information?