It is a bug report in a corner case.
When we assign "SECURITY DEFINER" attribute on plpgsql_call_handler(),
it makes server process crashed.
postgres=# ALTER FUNCTION plpgsql_call_handler() security definer;
ALTER FUNCTION
postgres=# CREATE FUNCTION foo(text) RETURNS text AS $$
BEGIN
RETURN $1 || '_aaa';
END
$$ LANGUAGE plpgsql;
CREATE FUNCTION
postgres=# select foo('aaa');
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: Failed.
!> \q
[scenario]
1. PostgreSQL calls fmgr_info_cxt_security() to initialize FmgrInfo
of the foo() invocation.
2. This invocation eventually calls fmgr_info_other_lang(), because
foo() is implemented with plpgsql. It also calls fmgr_info() to
fetch the function pointer of the plpgsql_call_handler().
3. However, this invocation returns fmgr_security_definer, because
it is marked as security definer function. Then, it is copied to
FmgrInfo->fn_addr of the foo().
4. Then, at the first call of fmgr_security_definer(), it also calls
fmgr_info_cxt_security() with ignore_security = true, to initialize
secondary FmgrInfo.
However, its fn_addr is initialized to fmgr_security_definer()
because of step (1) - (3).
5. Finally, fmgr_security_definer() calls itself infinity, as long as
stack is available.
I wonder whether the fmgr_info() is an appropriate choice at
fmgr_info_other_lang(), because user intended to call the foo(), not
plpgsql_call_handler(), although it actuall calls language call-handler
in fact.
I think fmgr_info_cxt_security() with ignore_security = true should
be used here, instead.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>