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();