From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: Karsten Hilbert <Karsten.Hilbert@gmx.net>,
        pgsql-general@lists.postgresql.org
Subject: Re: backend crash on DELETE, reproducible locally
In-reply-to: <20181101152723.zq2dtcgntmcmr4br@alvherre.pgsql>
References: <20181101152723.zq2dtcgntmcmr4br@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Thu, 01 Nov 2018 12:27:23 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <18071.1541087036.1@sss.pgh.pa.us>
Date: Thu, 01 Nov 2018 11:43:56 -0400
Message-ID: <18072.1541087036@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Ah, now this is interesting.  Can you please supply the definition of
> the table?  I'm wondering if there is a partitioned table with an FK to
> this one.  I'm not quite seeing how come 'tup' is NULL there.

Yeah, apparently we've passed a null OLD tuple to an RI_FKey_cascade_del
trigger, which surely shouldn't happen.  It'd be interesting to look at
the set of triggers on this table.  I don't entirely trust psql's \d
to show us reality if there's something screwed up about the triggers,
so in addition to \d output, could we see

select * from pg_trigger where tgrelid  = 'ref.auto_hint'::regclass;

			regards, tom lane