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

Поиск
Список
Период
Сортировка
От JanWieck@t-online.de (Jan Wieck)
Тема Re: Foreign key bugs (Re: [BUGS] "New" bug?? Serious - crashes backend.)
Дата
Msg-id 200007110920.LAA16722@hot.jw.home
обсуждение исходный текст
Ответ на Foreign key bugs (Re: [BUGS] "New" bug?? Serious - crashes backend.)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Foreign key bugs (Re: [BUGS] "New" bug?? Serious - crashes backend.)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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'swhere the
 
       DROP TABLE implicitly drops referential ...
   NOTICE message comes from. So I wonder how he got  into  that   state?


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #




В списке pgsql-hackers по дате отправления:

Предыдущее
От: JanWieck@t-online.de (Jan Wieck)
Дата:
Сообщение: Re: Software Quality
Следующее
От: JanWieck@t-online.de (Jan Wieck)
Дата:
Сообщение: Re: update on TOAST status'