Re: BUG #15703: Segfault in cancelled CALL-Statements

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