Re: backend crash on DELETE, reproducible locally
От | Tom Lane |
---|---|
Тема | Re: backend crash on DELETE, reproducible locally |
Дата | |
Msg-id | 32192.1541217418@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: backend crash on DELETE, reproducible locally (Karsten Hilbert <Karsten.Hilbert@gmx.net>) |
Ответы |
Re: backend crash on DELETE, reproducible locally
|
Список | pgsql-general |
Karsten Hilbert <Karsten.Hilbert@gmx.net> writes: > On Thu, Nov 01, 2018 at 11:43:56AM -0400, Tom Lane wrote: >> Yeah, apparently we've passed a null OLD tuple to an RI_FKey_cascade_del >> trigger, which surely shouldn't happen. It'd be interesting to look at >> the set of triggers on this table. I don't entirely trust psql's \d >> to show us reality if there's something screwed up about the triggers, >> so in addition to \d output, could we see >> select * from pg_trigger where tgrelid = 'ref.auto_hint'::regclass; > [ pretty normal-looking trigger entries ] I was feeling baffled about this, but it suddenly occurs to me that maybe the bug fixed in 040a1df61/372102b81 explains this. If the particular tuple you're trying to delete predates the last ALTER TABLE ADD COLUMN operation on the table, then this bug would result in t_self getting set to "invalid", which'd cause AfterTriggerSaveEvent to save "ate_ctid1" as "invalid", which'd lead to a null tuple getting passed when the trigger eventually gets invoked. regards, tom lane
В списке pgsql-general по дате отправления: