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-04T04:30:21Z
Lists: pgsql-bugs

Attachments

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

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.