[BUG] SECURITY DEFINER on call handler makes daemon crash

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(at)ak(dot)jp(dot)nec(dot)com>