Re: Prepared statements fail after schema changes with surprising error

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Prepared statements fail after schema changes with surprising error
Дата
Msg-id 20921.1358959244@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Prepared statements fail after schema changes with surprising error  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Prepared statements fail after schema changes with surprising error  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> I agree with that, but I think Tom's concern is more with the cost of
> too-frequent re-planning.  The most obvious case in which DDL might be
> frequent enough to cause an issue here is if there is heavy use of
> temporary objects - sessions might be rapidly creating and dropping
> objects in their own schemas.  It would be unfortunate if that forced
> continual replanning of queries in other sessions.  I think there
> could be other cases where this is an issue as well, but the
> temp-object case is probably the one that's most likely to matter in
> practice.

Yeah, that is probably the major hazard IMO too.  The designs sketched
in this thread would be sufficient to ensure that DDL in one session's
temp schema wouldn't have to invalidate plans in other sessions --- but
is that good enough?

Your point that the locking code doesn't quite cope with newly-masked
objects makes me feel that we could get away with not solving the case
for plan caching either.  Or at least that we could put off the problem
till another day.  If we are willing to just change plancache's handling
of search_path, that's a small patch that I think is easily doable for
9.3.  If we insist on installing schema-level invalidation logic, it's
not happening before 9.4.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Следующее
От: Robert Haas
Дата:
Сообщение: Re: CF3+4 (was Re: Parallel query execution)