Calling a PL/pgSQL procedure with a record "in out" formal crashes the postgres server process

[bllewell]

Jira Link: DB-1846

Using YugabyteDB Version 2.0.1.0 downloaded from the Internet. Running on my MacBook macOS Mojave Version 10.14.6. Cluster created with bare "yb-ctl create" — so RF=1, one node.

I wrote a procedure to work around the limitation that I mentioned in Issue #2596, brought by the fact that PL/pgSQL doesn't allow a subprogram to access and modify a global variable, by maintaining the cross-call state in a field subprogram's record "in out" formal. It works fine in PostgreSQL and produces the same value for the count of recursive calls to compute fib(n) that is produced by the Python recursive function implementation for the Nth Fibonacci number. It relies on a table created thus:

create table params_type(n integer, cnt integer, fib_n integer);

for the shape of the record.

The procedure is created thus:

create or replace procedure fib(params in out params_type)
  language 'plpgsql'
as $$
declare
  -- Use these constants to be 100% sure that there's no datatype conversion.
  zero constant integer not null := 0;
  one  constant integer not null := 1;
  two  constant integer not null := 2;
  n_in constant integer not null := params.n;

  fib_n_minus_1 integer not null := 0;
  fib_n_minus_2 integer not null := 02;
  dummy varchar(1);
begin
  params.cnt := params.cnt + one;

  -- Define fib(n) this way.
  if params.n < one then
    params.fib_n := zero;
  elsif params.n = one then
    params.fib_n := one;
  else
    params.n := params.n - 1;
    call fib(params);
    fib_n_minus_1 := params.fib_n;

    params.n := params.n - 1;
    call fib(params);
    fib_n_minus_2 := params.fib_n;

    params.n := n_in;
    params.fib_n := fib_n_minus_1 + fib_n_minus_2;
  end if;
end
$$;

I timed it thus:

\timing on
do $$
declare
  params params_type;
  n constant integer := 5;
begin
  params.n := n;
  params.cnt := 0;
  call fib(params::params_type);

  raise info '';
  raise info 'count = % fib(%) = %', params.cnt, n, params.fib_n;
  raise info '';
end
$$;
\timing off

It turns out that this implementation is significantly slower than the function implementation described in Issue #2596. Here are the times for PostgreSQL. The "funct" times are copied from Issue #2596

 N    Answer    Nr recursive calls    funct    proc
--   --------   ------------------   ------   -----
 3          2                    5     0.95    0.58
30     832040              2692537     7.90   27.28
35    9227465             29860703    89.17  304.30

When the same test is tried using YugabyteDB, it causes the Postgres server process to die. This message is produced at the ysqlsh prompt:

server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.