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.)
|
Список | 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 по дате отправления: