Re: BUG #15060: Row in table not found when using pg function in an expression

Поиск
Список
Период
Сортировка
От Marko Tiikkaja
Тема Re: BUG #15060: Row in table not found when using pg function in an expression
Дата
Msg-id CAL9smLDF9pZ89LWFgO4BcnMZf15EFiaxAhcnjuamS=HOKb+=NQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #15060: Row in table not found when using pg function in an expression  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #15060: Row in table not found when using pg function in an expression
Список pgsql-bugs
On Mon, Feb 12, 2018 at 9:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> So what's happening here is that the function get_bug_id, being stable,
> is being called speculatively at plan time for the query where it
> appears in the WHERE clause. For whatever reason, the snapshot it's
> being run in at that time is not the same one actually used for the
> later execution of the query, and the plan-time snapshot doesn't see the
> just-inserted row.

> It looks like what's going on here is that SPI does GetCachedPlan -
> which is where planning will happen - _before_ establishing the new
> snapshot in the non-read-only case (read_only is false here because the
> calling function, test_bug(), is volatile).

Yeah, I came to the same conclusion.  I think it's basically accidental
that the given test case works before 9.2: the reason seems to be that
in 9.1, the plancache doesn't pass through the parameter list containing
the value of "my_text", so that the planner is unable to speculatively
execute get_bug_id().  The order of operations in _SPI_execute_plan
is just as wrong though.

I'm not sure I understand.  When's the snapshot used for planning actually taken here?


.m

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: BUG #15061: Cannot use TEMP TABLE ON COMMIT DROP in extension
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #15062: Calling 3 function in one other function