[EMAIL PROTECTED] (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 --- th
> [EMAIL PROTECTED] (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 wi
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> 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.
> I like a different routine name better than a check-or-no-check
> parameter. If you invoke the no-check case then you *MUST* have a check
> for failure return --- forgetting to do this is exactly the problem.
> So I think it should be harder to get at the no-check case, and you
> should have to
Tom Lane wrote:
>
> >> 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 s
[EMAIL PROTECTED] (Jan Wieck) writes:
> Tom Lane wrote:
>> 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
