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

From Bruce Momjian
Subject Re: Foreign key bugs (Re: [BUGS] "New" bug?? Serious - crashes backend.)
Date
Msg-id 200007111534.LAA05463@candle.pha.pa.us
Whole thread Raw
In response to Re: Foreign key bugs (Re: [BUGS] "New" bug?? Serious - crashes backend.)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Foreign key bugs (Re: [BUGS] "New" bug?? Serious - crashes backend.)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> 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?

We already have heap_open and heap_openr.  Seems another is too hard. 
Better to give them a parameter to control it.  The API is confusing enough.



--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Foreign key bugs (Re: [BUGS] "New" bug?? Serious - crashes backend.)
Next
From: Tom Lane
Date:
Subject: Re: update on TOAST status'