From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4 |
Date: | 2009-07-14 16:51:33 |
Message-ID: | 25268.1247590293@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> 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?
> Do we have the stuff where an ANALYZE could invalidate cached plans?
That was true in 8.3, too. But it doesn't affect this particular code
path because exec_eval_simple_expr won't be used for anything that
references a table. In 8.4 you could have a plan inval on an expression
that just uses a user-defined function, but it's a lot harder to trigger
such a thing in 8.3. Which is why we didn't get reports before.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-07-14 16:54:17 | Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4 |
Previous Message | Tom Lane | 2009-07-14 16:43:23 | Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4 |