On Tue, Mar 19, 2019 at 10:04:55AM +0000, PG Bug reporting form wrote:
> there seems to be a SEGFAULT issue with CALL-Procedures once they get
> SIGINT'ed. While currently able to reproduce with non-disclosed
> functions and data- I am working on a minimal report for public
> reproduction.
It would be nice to have a reproducible test case. From what I can
see, we don't have the definition of "procedure" which gets called at
the highest level, so it is not possible to use your example. I have
been playing a bit with query cancellations and some nested
procedures, but could not see an issue:
CREATE TABLE aa (a int);
CREATE OR REPLACE PROCEDURE insert_tuples(num_tuples int)
AS $func$
BEGIN
CALL insert_tuples_inner(num_tuples);
END
$func$ LANGUAGE plpgsql;
CREATE OR REPLACE PROCEDURE insert_tuples_inner(num_tuples int)
AS $func$
BEGIN
FOR i IN 1..num_tuples LOOP
EXECUTE format('INSERT INTO aa VALUES (' || i || ');');
END LOOP;
END
$func$ LANGUAGE plpgsql;
Then just do that in parallel between two sessions. One for the
cancellation:
while true; do
psql -c "select pg_cancel_backend(pid) from pg_stat_activity where
pid <> pg_backend_pid() and query ~ 'insert_tuples'";
sleep 5;
done
And another one for the repeated procedure calls, which uses CALL
insert_tuples(1000000) as query to run multiple times.
--
Michael
