Re: [HACKERS] Foreign key bugs (Re: "New" bug?? Serious - crashes backend.)

JanWieck(at)t-online(dot)de (Jan Wieck) writes:
> Tom Lane wrote:
>> There are at least two bugs here: the immediate cause of the crash
>> is lack of a check for heap_openr() failure in the RI trigger code,

> Exactly where is that check missing (if it still is)?

The heap_openr calls with NoLock --- the way heap_open[r] are set up
is that there's an elog on open failure iff you request a lock, but
if you don't then you have to check for a NULL return explicitly.
Perhaps this coding convention is too error-prone and ought to be
changed to have two different routine names, say "heap_open[r]"
and "heap_open[r]_noerr". Opinions anyone?

I had a note to myself that ri_triggers' use of NoLock was probably
a bug anyway. Shouldn't it be acquiring *some* kind of lock on the
referenced relation? Else someone might be deleting it out from
under you.

>> but a larger question is why the system let you drop a table that
>> is the target of a referential integrity check (which I assume is
>> what you did to get into this state).

> For me too.

What about renaming as opposed to dropping? Since the triggers are set
up to use names rather than OIDs, seems like they are vulnerable to a
rename. Maybe they should be using table OIDs in their parameter lists.
(That'd make pg_dump's life harder however...)

regards, tom lane