Re: Bypassing cursors in postgres_fdw to enable parallel plans

On Tue, 21 Jul 2026 at 19:35, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, Jul 21, 2026 at 2:41 AM Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>
> wrote:
> > Yes you are right, this was based on the existing flow of pendingAreq,
> but also because we have access to conn_state in this function. In the
> functions pgfdw_cancel_query_end and pgfdw_get_cleanup_result we are only
> dealing with conn only, so clearing the conn_state there doesn't seem
> possible without significant changes.
>
> I think you can add a parameter to pgfdw_cancel_query and
> pgfdw_cancel_query_end, a PgFdwConnState. The callers in connection.c
> have a ConnCacheEntry and can pass &entry->state, and the callers in
> postgres_fdw.c have a PgFdwScanState and can pass fsstate->conn_state.
>
> Yes, you are right we can do that. However, looking at it more closely,
zeroing the conn_state which includes pendingAreq doesn't look right.
Because in pgfdw_abort_cleanup, when the check is done for pendingAreq, it
would always be false, since we have cleared it already. So, wouldn't
doing active_scan = NULL in pgfdw_cancel_query_end make more sense here
rather than zeroing...?

> --
> Robert Haas
> EDB: http://www.enterprisedb.com
>

--
Regards,
Rafia Sabih
CYBERTEC PostgreSQL International GmbH