On Tue, 21 Jul 2026 at 19:35, Robert Haas <[email protected]> wrote:
> On Tue, Jul 21, 2026 at 2:41 AM Rafia Sabih <[email protected]> > 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
