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