Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4 - Mailing list pgsql-bugs

From Tom Lane
Subject Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4
Date
Msg-id 16998.1247582529@sss.pgh.pa.us
Whole thread Raw
In response to Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4  (Frank van Vugt <ftm.van.vugt@foxi.nl>)
Responses Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4  (Frank van Vugt <ftm.van.vugt@foxi.nl>)
Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-bugs
Frank van Vugt <ftm.van.vugt@foxi.nl> writes:
>> Hmph.  So evidently the unexpected recursion into SPI is happening when
>> a cached plan has to be recomputed.  I suspected something of the sort,
>> but now the question is why you didn't see the same problem in 8.3 ...

> Just as an additional confirmation: nothing else but the db changed when we
> migrated from 8.3.7 to 8.4.0 last weekend

I'm convinced that 8.3 has the same bug, in the sense that it could fail
this way if it had to revalidate a cached plan.  Probably the reason you
didn't see it before is that 8.4 has more conditions in which it will
invalidate cached plans.  In particular, is it possible that this
failure occurs when you try to call a plpgsql function that has just
been replaced via CREATE OR REPLACE FUNCTION?

[ looks at CVS logs ... ]  Another case that will cause plan
invalidation in 8.4 and not 8.3 is creating or dropping a schema.
Do you do a lot of that?

            regards, tom lane

pgsql-bugs by date:

Previous
From: Frank van Vugt
Date:
Subject: Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4
Next
From: Heikki Linnakangas
Date:
Subject: Re: BUG #4919: CREATE USER command slows down system performance