Ranier Vilela writes:
> Em qui., 27 de jun. de 2024 às 13:18, Tom Lane escreveu:
>> 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
Em qui., 27 de jun. de 2024 às 13:18, Tom Lane 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 coul
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 ji
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
I wrote:
> It gets a SIGSEGV in plpgsql_transaction.sql's
> cursor_fail_during_commit test.
Here's a simpler way to reproduce: just run the attached script
in a --with-llvm build. (This is merely extracting the troublesome
regression case for convenience.)
Interesting, if you take out any one of
Ranier Vilela writes:
> Em qua., 26 de jun. de 2024 às 15:09, Tom Lane escreveu:
>> lineno = 843 matches the expected error location in int4_div().
> Did you mean *int4div*, right?
Right, typo.
regards, tom lane
Em qua., 26 de jun. de 2024 às 15:09, Tom Lane escreveu:
> I initially ran into this while trying to reproduce the recent
> reports of trouble with LLVM 14 on ARM. However, it also reproduces
> with LLVM 17 on x86_64, and I see no reason to think it's at all
> arch-specific. I also reproduced i
