Re: BUG #16036: Segmentation fault while doing an update - Mailing list pgsql-bugs

From Andres Freund
Subject Re: BUG #16036: Segmentation fault while doing an update
Date
Msg-id 20191004043021.ylfbxcjqyypphfft@alap3.anarazel.de
Whole thread Raw
In response to Re: BUG #16036: Segmentation fault while doing an update  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #16036: Segmentation fault while doing an update  (Andres Freund <andres@anarazel.de>)
List 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.

Here's 1, 2 & 4, working on fixing 3).  While we now have OK-ish
coverage for nodeModifyTable.c and nodeLockRows.c triggered EPQ, there's
not much for the trigger case.

Greetings,

Andres Freund

Attachment

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #16036: Segmentation fault while doing an update
Next
From: PG Bug reporting form
Date:
Subject: BUG #16037: Assertion fails in varbit_out