Re: BUG #16036: Segmentation fault while doing an update

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Антон Власов <druidvav(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16036: Segmentation fault while doing an update
Date: 2019-10-04 03:36:10
Message-ID: 20191004033610.fb47ehgycodogn6w@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

On 2019-10-03 23:26:01 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2019-10-04 03:42:43 Re: BUG #16036: Segmentation fault while doing an update
Previous Message Tom Lane 2019-10-04 03:26:01 Re: BUG #16036: Segmentation fault while doing an update