Re: BUG #16184: Segmentation Fault during update

Hi,

I don't know what is EvalPlanQual but conditions you wrote about are met.

Table which is updated is main table and it name is job_abstract. The're a
lot of another tables for example job_bca, job_mod, job_smth which extends
job_abstract.

In my case situation is as follows: in the same time it's possible that
some different transactions are in progress (started but not
committed yet). The're some legacy (looks like some kind of guard) that
update under some conditions table job_abstract. In another transaction(s)
table job_bca (which extends job_abstract - inheritance) is updated too.
This two (or more) transactions are updating the same rows, but different
set of fields. I think that author of this update tried to force change
xmax of job_abstract making dumb update job_status = 0 where ... job_status
= 0. But everything works fine to postgres 11.5. When we upgreade to 12.1
segmentation fault occurs. But i saw in commit you linked to description:
"Back-patch to v12 where the bug was introduced".

On Fri, Jan 31, 2020 at 6:41 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> =?UTF-8?Q?Piotr_W=C5=82odarczyk?= <piotrwlodarczyk89(at)gmail(dot)com> writes:
> > sorry for the late reply, but it was not so easy to get more logs. So
> what
> > we have now is listed below:
>
> > (gdb) bt
> > #0 0x0000000000616912 in EvalPlanQualBegin (epqstate=epqstate(at)entry
> =0x2ae9520)
> > at execMain.c:2735
> > #1 0x0000000000616cfb in EvalPlanQual (epqstate=epqstate(at)entry
> =0x2ae9520,
> > relation=relation(at)entry=0x7f694c76f838, rti=14,
> > inputslot=inputslot(at)entry=0x31bc408)
> > at execMain.c:2454
> > #2 0x0000000000638bdf in ExecUpdate (mtstate=mtstate(at)entry=0x2ae9428,
> > tupleid=0x7ffc94e3cf40, oldtuple=0x0, slot=<optimized out>,
> > planSlot=0x312fc28, epqstate=epqstate(at)entry=0x2ae9520,
> > estate=estate(at)entry=0x2aff450,
> > canSetTag=true) at nodeModifyTable.c:1387
> > #3 0x000000000063914d in ExecModifyTable (pstate=0x2ae9428) at
> > nodeModifyTable.c:2223
>
> OK, so that confirms my suspicion that it was an EvalPlanQual issue
> (hence, you need concurrent updates on the same row to trigger it).
>
> I believe this might be the same bug we isolated and fixed just a
> couple of days ago:
>
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=87fed2a197abc1397b63ee74b3fa7eb20471fff5
>
> The stack trace looks the same as what Oleksii showed in that thread
> for a non-assert build. As far as I know, that bug only triggers if
> a single ModifyTable plan node has to run EPQ checks for more than
> one target table --- so, is this query updating a partitioned table
> or inheritance tree, and is it plausible that it had to update rows
> in more than one sub-table, and that some other transaction(s) were
> concurrently updating those same rows?
>
> regards, tom lane
>

--

Pozdrawiam
Piotr Włodarczyk