BUG #11902: PostgreSQL 9.5 crashes on alter table in function

The following bug has been logged on the website:

Bug reference:      11902
Logged by:          Regina Obe
Email address:      lr@pcorp.us
PostgreSQL version: Unsupported/Unknown
Operating system:   Debian and Windows MingW-w64 (both 64 and 32-bit)
Description:

I wanted to pick 9.5 in PostgreSQL version, but that is not listed.  Anyway
for the past couple of weeks regressing against latest snapshots of 9.5 has
been crashing our PostGIS topology tests.

Related ticket here:
http://trac.osgeo.org/postgis/ticket/2982

I was able to crash without PostGIS help with this script:

CREATE OR REPLACE FUNCTION crash_test(table_name varchar, column_name
varchar)
  RETURNS bigint AS
$$
DECLARE
 var_result bigint;
BEGIN
       EXECUTE 'ALTER TABLE ' || quote_ident(table_name) || ' ADD COLUMN '
|| quote_ident(column_name) || ' text;';
       var_result = (random()*100000)::bigint;
       RETURN var_result;
END
$$
  LANGUAGE plpgsql VOLATILE
  COST 100;

DROP TABLE IF EXISTS test_1;
CREATE TABLE test_1(id serial primary key);
DROP TABLE IF EXISTS test_crash;
CREATE TEMP TABLE test_crash AS
SELECT 1 As id, crash_test('test_1', 'lyr1') As layer;

INSERT INTO test_crash(id, layer)
SELECT id + 1, crash_test('test_1', 'lyr' || (id + 1)::text)
FROM test_crash
WHERE id = 1;


Our buildbot runs Debian 64-bit, and I also tested this on my Mingw64
Windows 7 both (64-bit and 32-bit with same issue)

Issue seems to be around here according to gdb trace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 5568.0x15c4]
0x000000000054fbc9 in AfterTriggerPendingOnRel (relid=17984) at
trigger.c:4781
4781                    for_each_event_chunk(event, chunk,
afterTriggers.query_stack[depth])
(gdb) bt
#0  0x000000000054fbc9 in AfterTriggerPendingOnRel (relid=17984) at
trigger.c:4781
#1  0x000000000053e05c in CheckTableNotInUse (rel=0xe650dc0, stmt=0x8ab69a
<__func__.77621+8091> "ALTER TABLE") at tablecmds.c:2652
#2  0x0000000000545315 in AlterTable (relid=relid@entry=17984,
lockmode=lockmode@entry=8, stmt=0xe32b580) at tablecmds.c:2724