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

Etsuro Fujita <etsuro.fujita@gmail.com>

From: Etsuro Fujita <etsuro.fujita@gmail.com>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2022-01-30T10:59:19Z
Lists: pgsql-bugs
Hi Alexander,

On Tue, Jan 25, 2022 at 3:00 AM Alexander Lakhin <exclusion@gmail.com> wrote:
> I've made a simple isolation test (see attachment) to confirm this. And
> it crashes without the fix as you said.
> With your fix it works as expected

Thanks for testing!

> (I was wondering how "plan->operation
> != CMD_SELECT" with RETURNING will work and I haven't seen any issues yet.)

EvalPlanQual rechecking is irrelevant for direct modifications even
when the UPDATE/DELETE query has a RETURNING clause; in which case we
compute the RETURNING expressions locally, but that is done *after*
updating/deleting foreign rows on the remote side.

> (Besides that I've observed an infinite waiting for ShareLock with
> step "s1i" { INSERT INTO pt VALUES (2000); }
> This doesn't happen with a regular (not foreign) table.)

You mean the lock wait occurs on the remote side, not on the local
side?  If so, I think that that is expected behavior because a write
conflict occurs on the remote side in that case.  Maybe I don’t fully
understand your words, so could you elaborate a bit more on your
observation?

Best regards,
Etsuro Fujita



Commits

  1. Further fix for EvalPlanQual with mix of local and foreign partitions.

  2. Fix segfault during EvalPlanQual with mix of local and foreign partitions.

  3. Rework planning and execution of UPDATE and DELETE.