Em qui., 27 de jun. de 2024 às 13:18, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
I wrote: > So delaying removal of the jit-created code segment until transaction > cleanup wouldn't be enough to prevent this crash, if I'm reading > things right. The extra-pstrdup solution may be the only viable one.
> I could use confirmation from someone who knows the JIT code about > when jit-created code is unloaded. It also remains very unclear > why there is no crash if we don't force both jit_optimize_above_cost > and jit_inline_above_cost to small values.
I found where the unload happens: ResOwnerReleaseJitContext, which is executed during the resource owner BEFORE_LOCKS phase. (Which seems like a pretty dubious choice from here; why can't we leave it till the less time-critical phase after we've let go of locks?) But anyway, we definitely do drop this stuff during xact cleanup.
Also, it seems that the reason that both jit_optimize_above_cost and jit_inline_above_cost must be small is that otherwise int4div is simply called from the JIT-generated code, not inlined into it. This gives me very considerable fear about how well that behavior has been tested: if throwing an error from inlined code doesn't work, and we hadn't noticed that, how much can it really have been exercised? I have also got an itchy feeling that we have code that will be broken by this behavior of "if it happens to get inlined then string constants aren't so constant".
In any case, I found that adding some copying logic to CopyErrorData() is enough to solve this problem, since the SPI infrastructure applies that before executing xact cleanup.
In this case, I think that these fields, in struct definition struct ErrorData (src/include/utils/elog.h)
