On Fri, Jan 7, 2022 at 3:19 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> On Thu, Jan 6, 2022 at 9:00 PM Alexander Lakhin <exclusion@gmail.com> wrote:
> > 06.01.2022 12:56, Etsuro Fujita wrote:
> > > I haven't tried to reproduce this yet
I think a simple reproducer for this issue is:
1) Define the partitioned table async_pt as shown by Alexander.
2) Run concurrent transactions as follows.
Session A: insert into async_pt values (3000);
Session A: begin;
Session A: update async_pt set a = a;
Session B: delete from async_pt;
Session A: commit;
The commit in Session A would cause a server crash in Session B due to
the segmentation fault.
Also, I think a simple reproducer for the “cannot re-evaluate a
Foreign Update or Delete during EvalPlanQual” error is:
1) Define the partitioned table async_pt as shown by Alexander.
2) Run concurrent transactions as follows.
Session A: insert into async_pt values (3000);
Session A: begin;
Session A: update async_pt set a = a;
Session B: update async_pt set a = a;
Session A: commit;
The commit in Session A would cause the transaction in Session B to
abort with that error.
I think the root cause of these issues is that because of the rework
for inherited UPDATE/DELETE in commit 86dc90056, ForeignScan nodes
doing direct modifications are re-evaluated as part of the
EvalPlanQual subtree when doing an EvalPlanQual check, which breaks
the assumption that those ForeignScan nodes should never be
re-evaluated by EvalPlanQual, leading to these issues. To fix, I’d
like to propose to ignore those ForeignScan nodes in
ExecForeignScan/ExecReScanForeignScan when doing that recheck, like
the attached.
Best regards,
Etsuro Fujita