Re: BUG #16036: Segmentation fault while doing an update
От | Andres Freund |
---|---|
Тема | Re: BUG #16036: Segmentation fault while doing an update |
Дата | |
Msg-id | 20191004033610.fb47ehgycodogn6w@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: BUG #16036: Segmentation fault while doing an update (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #16036: Segmentation fault while doing an update
|
Список | pgsql-bugs |
Hi, On 2019-10-03 23:26:01 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > So I think what we need to do is: > > 1) only call ExecCopySlot() if slot != newslot - this fixes the crash > > 2) Add an assert to ExecCopySlot() ensuring source and target slot are > > distinct > > 3) Figure out why our tests didn't catch this, this afaict should be a > > tested scenario > > 4) Fix confusing variable naming around newSlot/newslot in ExecBRUpdateTriggers > > Maybe instead of 1+2, change ExecCopySlot like this: > > - dstslot->tts_ops->copyslot(dstslot, srcslot); > + if (dstslot != srcslot) > + dstslot->tts_ops->copyslot(dstslot, srcslot); > > That would fix other similar instances, not just this one caller. Yea, I was wondering about that too - but asking for a slot to be copied into itself seems to indicate a logic bug more often than not? Expecting the slots to be independent, afterwards. So I'm a bit hesitant doing so. Greetings, Andres Freund
В списке pgsql-bugs по дате отправления: