Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4
Дата
Msg-id 16998.1247582529@sss.pgh.pa.us
обсуждение исходный текст
Ответ на 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  (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>)
Список 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 по дате отправления:

Предыдущее
От: Frank van Vugt
Дата:
Сообщение: Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: BUG #4919: CREATE USER command slows down system performance