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

JanWieck@t-online.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