Re: Bypassing cursors in postgres_fdw to enable parallel plans

On Thu, Jul 23, 2026 at 6:03 AM Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com> wrote:
>> 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...?

I'm not entirely sure I understand the question. I'd generally
recommend clearing individual fields of a structure over using memset
to zeroing the entire thing. On that note, I wonder if the memset that
the current code uses in pgfdw_abort_cleanup() is buggy -- how can it
justify zeroing the *entire* state entry? I guess maybe that works
today because the only member of PgFdwConnState is pendingAreq, but it
doesn't seem like the right thing in general.

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