Re: BUG #17355: Server crashes on ExecReScanForeignScan in postgres_fdw when accessing foreign partition

On Fri, Jan 7, 2022 at 3:19 PM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
> On Thu, Jan 6, 2022 at 9:00 PM Alexander Lakhin <exclusion(at)gmail(dot)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