Horton

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

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Антон Власов <druidvav@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2019-10-04T03:36:10Z
Lists: 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

Commits

  1. Disable one more set of tests from c8841199509.

  2. Disable one set of tests from c8841199509.

  3. Add isolation tests for the combination of EPQ and triggers.

  4. Fix crash caused by EPQ happening with a before update trigger present.

  5. Modify the isolation tester so that multiple sessions can wait.