| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com> |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Segfault due to NULL ParamExecData value |
| Date: | 2025-12-04 15:35:36 |
| Message-ID: | 1051948.1764862536@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com> writes:
> So it looks like the ParamExec for the InitPlan 5 was correctly executed
> (since execPlan is null) and the value was probably used during the first
> two updates. But for the third update, the ParamExecData's value was null
> leading to the segfault.
> All coredumps (or rather WAL records) show a similar pattern of 2 updates
> before segfaults.
> I haven't been able to reproduce the segfault so I wasn't able to pinpoint
> what could have set ParamExecData's value to null.
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.
Don't suppose you can try to reproduce this on something newer
than 14.17?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2025-12-04 17:14:51 | Re: BUG #19341: REPLACE() fails to match final character when using nondeterministic ICU collation |
| Previous Message | Anthonin Bonnefoy | 2025-12-04 14:25:55 | Segfault due to NULL ParamExecData value |