Re: Consistent segfault in complex query

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: Consistent segfault in complex query
Дата
Msg-id 87worpm7qx.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: Consistent segfault in complex query  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Consistent segfault in complex query  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 >> So I can see exactly where the problem is, but I'm not sure what the
 >> solution should be.

 >> EvalPlanQualStart copies the param_exec value list explicitly _not_
 >> including the execPlan link, which obviously isn't going to work if
 >> the value has not been computed yet. Should it be forcing the
 >> evaluation of initplans that haven't been run yet, or should the EPQ
 >> scan evaluate them itself from a copy of the plan, or does there
 >> need to be some way to share state? (having the InitPlan be run more
 >> than once might be a problem?)

 Tom> The second of those; what we need is for any referenced InitPlans
 Tom> to be executed afresh under EPQ rules. (I'm not entirely sure that
 Tom> an InitPlan could need to see different input tuples under EPQ
 Tom> than it'd see otherwise, but I'm not sure it couldn't, either.)

Obviously you know this code better than I do... but I'm not convinced.

Shouldn't the InitPlan pretty much by definition be independent of the
tuples being locked/updated?

And doesn't executing them again run the risk of getting a different
value for other reasons, for example if an initplan is volatile?

What I'm wondering is whether the param in the copied estate shouldn't
rather be just a proxy for the one in the original estate - if we need
to evaluate it, then do so in the original estate, store the value
there, and copy the value back into the EPQ plantree.

-- 
Andrew (irc:RhodiumToad)


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_dump test instability
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Bug fix for glibc broke freebsd build in REL_11_STABLE