Plan invalidation vs temp sequences

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Plan invalidation vs temp sequences
Дата
Msg-id 28253.1192062013@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: Plan invalidation vs temp sequences  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Re: Plan invalidation vs temp sequences  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-hackers
In bug #3662
http://archives.postgresql.org/pgsql-bugs/2007-10/msg00047.php

we see that it doesn't work to do nextval('seq') on a temp sequence
in a plpgsql function except via EXECUTE, because the sequence OID gets
embedded into the cached plan, same as any other temp table.  This is to
be expected in existing releases, but I notice it still doesn't work in
CVS HEAD, which is a tad annoying given the existence of the plan inval
mechanism.  The reason is that plancache.c only searches the plan's
RangeTable for references to a just-invalidated relation; and the
argument of nextval() isn't mentioned in the RangeTable (it is in fact
just a Const of type regclass).

There doesn't seem to be any very nice way to fix this.  There is
not any existing support mechanism (comparable to query_tree_walker)
for scanning whole plan trees, which means that searching a cached plan
for regclass Consts is going to involve a chunk of new code no matter
how we approach it.  We might want to do that someday --- in particular,
if we ever try to extend the plan inval mechanism to react to
redefinitions of non-table objects, we'd likely need some such thing
anyway.  I'm disinclined to try to do it for 8.3 though.  The use-case
for temp sequences seems a bit narrow and there are several workarounds
(see followups to bug report), so I'm feeling this is a
fix-some-other-day kind of issue.

Comments?
        regards, tom lane


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

Предыдущее
От: Florian Pflug
Дата:
Сообщение: Re: Skytools committed without hackers discussion/review
Следующее
От: "Robert A. Klahn"
Дата:
Сообщение: Artificially increase TransactionID?