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 04:30:21 |
Message-ID: | 20191004043021.ylfbxcjqyypphfft@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.
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 | Content-Type | Size |
---|---|---|
wip-fix-16036.patch | text/x-diff | 3.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2019-10-04 05:00:00 | BUG #16037: Assertion fails in varbit_out |
Previous Message | Tom Lane | 2019-10-04 03:42:43 | Re: BUG #16036: Segmentation fault while doing an update |