Em qui., 27 de jun. de 2024 às 13:18, Tom Lane <t...@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) should be changed too? from const char * to char* best regards, Ranier Vilela
