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)?
> 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.
> Anyway, dropping the siteid trigger, as well as any others that
> refer to gone tables, ought to get you out of trouble for now.
> Meanwhile the foreign-key boys have some work to do ...
That's exactly the purpose of pg_trigger.tgconstrrelid, which
is filled with the opposite relations Oid for constraint
triggers. In RelationRemoveTriggers(), which is called
during DROP TABLE, theres a scan for it. That's where the
DROP TABLE implicitly drops referential ...
NOTICE message comes from. So I wonder how he got into that
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
In response to
pgsql-hackers by date
|Next:||From: Jan Wieck||Date: 2000-07-11 10:09:14|
|Subject: Re: Storage Manager (was postgres 7.2 features.)|
|Previous:||From: Karel Zak||Date: 2000-07-11 09:05:56|
|Subject: Re: Distribution making|
pgsql-bugs by date
|Next:||From: Tom Lane||Date: 2000-07-11 15:26:36|
|Subject: Re: [HACKERS] Foreign key bugs (Re: "New" bug?? Serious - crashes backend.) |
|Previous:||From: Tom Lane||Date: 2000-07-11 03:26:38|
|Subject: Foreign key bugs (Re: "New" bug?? Serious - crashes backend.)|