Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4
Date: 2009-07-14 14:42:09
Message-ID: 16998.1247582529@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Heikki Linnakangas 2009-07-14 15:09:15 Re: BUG #4919: CREATE USER command slows down system performance
Previous Message Frank van Vugt 2009-07-14 14:34:48 Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4