Re: Segfault due to NULL ParamExecData value
| От | Anthonin Bonnefoy |
|---|---|
| Тема | Re: Segfault due to NULL ParamExecData value |
| Дата | |
| Msg-id | CAO6_XqrLc0NbO0en=CQ=xibPHugRUsoh9WuTU4LFTD1268E3Tg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Segfault due to NULL ParamExecData value (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-bugs |
On Thu, Dec 4, 2025 at 4:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
I'm not volunteering to look into this without a reproducer.
However, seeing that EvalPlanQual is in the stack trace,
my gut feeling is that the EPQ mechanism is somehow mis-managing
output Params for InitPlans. I vaguely recall some definitional
issues around whether it'd be okay to pass down already-computed
InitPlan results into the EPQ sub-evaluation, or whether we should
force the sub-evaluation to do those afresh. It was awhile back
and I don't remember what was decided.
That sounds like an interesting lead. The impacted cluster definitely had a lot of long transactions updating the same rows with the occasional deadlocks.
Don't suppose you can try to reproduce this on something newer
than 14.17?
That would be hard. On the production cluster, we've stopped the segfaults by rewriting the query (faster execution time, so less recheck and EPQ?) and I don't have much leeway to experiment on those.
I'm currently working on a backup of the cluster trying to redo the same queries using 14.17, since the issue was happening with this version. If I manage to have a reproducer, I will check newer versions. I will focus on triggering the EPQ since that looks like a good lead.
Regards,
Anthonin Bonnefoy
В списке pgsql-bugs по дате отправления: