Re: BUG #16184: Segmentation Fault during update - Mailing list pgsql-bugs
| From | Piotr Włodarczyk |
|---|---|
| Subject | Re: BUG #16184: Segmentation Fault during update |
| Date | |
| Msg-id | CAP-dhMpT8g4gRwoOBmx6V21up_Q7wvXa3RoSVX=nTD9XQtgKpQ@mail.gmail.com Whole thread Raw |
| In response to | Re: BUG #16184: Segmentation Fault during update (Tom Lane <tgl@sss.pgh.pa.us>) |
| Responses |
Re: BUG #16184: Segmentation Fault during update
(Tom Lane <tgl@sss.pgh.pa.us>)
|
| List | pgsql-bugs |
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@sss.pgh.pa.us> wrote:
Piotr Włodarczyk <piotrwlodarczyk89@gmail.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@entry=0x2ae9520)
> at execMain.c:2735
> #1 0x0000000000616cfb in EvalPlanQual (epqstate=epqstate@entry=0x2ae9520,
> relation=relation@entry=0x7f694c76f838, rti=14,
> inputslot=inputslot@entry=0x31bc408)
> at execMain.c:2454
> #2 0x0000000000638bdf in ExecUpdate (mtstate=mtstate@entry=0x2ae9428,
> tupleid=0x7ffc94e3cf40, oldtuple=0x0, slot=<optimized out>,
> planSlot=0x312fc28, epqstate=epqstate@entry=0x2ae9520,
> estate=estate@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
pgsql-bugs by date: