From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: JIT causes core dump during error recovery |
Date: | 2024-06-26 20:01:47 |
Message-ID: | 1577388.1719432107@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> What I think is the right solution is to fix things so that
> seemingly-no-longer-used jit compilations are not thrown away
> until transaction cleanup. I don't know the JIT code nearly
> well enough to take point on fixing it like that, though.
Or maybe not. I found by bisecting that it doesn't fail before
2e517818f (Fix SPI's handling of errors during transaction commit).
A salient part of that commit message:
Having made that API redefinition, we can fix this mess by having
SPI_commit[_and_chain] trap errors and start a new, clean transaction
before re-throwing the error. Likewise for SPI_rollback[_and_chain].
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jelte Fennema-Nio | 2024-06-26 20:02:08 | Re: libpq: Fix lots of discrepancies in PQtrace |
Previous Message | Peter Eisentraut | 2024-06-26 19:32:27 | Re: New standby_slot_names GUC in PG 17 |