Re: Bypassing cursors in postgres_fdw to enable parallel plans

On Thu, 16 Jul 2026 at 12:24, Yilin Zhang <jiezhilove(at)126(dot)com> wrote:

> At 2026-07-15 11:50:32，"Rafia Sabih" <rafia(dot)pghackers(at)gmail(dot)com> wrote
> > Hello Yilin,
> > Thanks for your input. But unfortunately I am not able to reproduce the
> > issue with this test case. Also, I am not able to understand it much, as
> to
> > how we are going to access bug2_pid from session 2, because it is a temp
> > table from a different session. Maybe you can simplify this a little
> more,
> > or maybe share the backtrace in case of the crash.
>
> > Yes you are right, this was the gap, in case of crash while draining,
> > active_fsstate couldn't be cleared and a dangling pointer was left, which
> > causes the crash on the next execution.
> > To fix this, I have now added a condition in pgfdw_abort_cleanup, to
> reset
> > the active_scan in case of unfinished drain. Since I was not able to use
> > your test case so I couldn't verify if this fixes the issue.
> > Apart from that I have now changed the save_to_tuplestore function to
> only
> > have active_fsstate and PGconn. Also, there is a wrapper function to call
> > it and check the relevant condition so we don't duplicate it all those 5
> > places. I have also added the calls to function to drain tuples to
> > tuplestore in execute_dml_stmt and exectute_foreign_modify, to ensure
> that
> > whenever a new query is sent on the connection, we perform the draining
> of
> > the tuples to tuplestore if any or mark the other scan completed
> > appropriately.
>
> Sorry, that was my mistake.
> The temp keyword in the "CREATE TEMP TABLE" statement is unnecessary;
> just remove it directly.
>
Nevertheless, your input was valuable in finding the issue and fixing it.

> This crash has already been fixed in the v13 patch.
> LGTM.
>
> Hey, thanks a lot for confirming this.

>
>
> Best regards,
> --
> Yilin Zhang
>
>
>

--
Regards,
Rafia Sabih
CYBERTEC PostgreSQL International GmbH