Re: JIT causes core dump during error recovery - Mailing list pgsql-hackers

From Tom Lane
Subject Re: JIT causes core dump during error recovery
Date
Msg-id 1572310.1719429239@sss.pgh.pa.us
Whole thread Raw
In response to JIT causes core dump during error recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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 the three "set" commands,
it doesn't crash.  This probably explains why, for example,
buildfarm member urutu hasn't shown this --- it's only reducing
one of the three costs to zero.

I don't have any idea what to make of that result, except that
it suggests the problem might be at least partly LLVM's fault.
Surely, if we are prematurely unmapping a compiled code segment,
that behavior wouldn't depend on whether we had asked for
inlining?

            regards, tom lane

drop table if exists test1;
create table test1 (x int);

CREATE OR REPLACE PROCEDURE cursor_fail_during_commit()
 LANGUAGE plpgsql
AS $$
  DECLARE id int;
  BEGIN
    FOR id IN SELECT 1/(x-1000) FROM generate_series(1,1000) x LOOP
        INSERT INTO test1 VALUES(id);
        COMMIT;
    END LOOP;
  END;
$$;

set jit_above_cost=0;
set jit_optimize_above_cost=0;
set jit_inline_above_cost=0;

CALL cursor_fail_during_commit();

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)
Next
From: "David E. Wheeler"
Date:
Subject: Re: Proposal: Document ABI Compatibility