On Sat, Mar 21, 2026 at 1:14 AM Matheus Alcantara <[email protected]> wrote: > On 20/03/26 05:27, Chao Li wrote: > > I am not very familiar with the FDW code, so I am not ready to suggest a > > concrete fix. But it seems wrong to let later paths keep using > > PgFdwScanState->conn after select * from ft1 has already failed with > > connection loss. My guess is that we either need to invalidate all > > dependent state when disconnect_pg_server() runs, or otherwise prevent > > later cleanup paths from touching the cached PGconn *. > > Although I agree with this I think that it will be a quite invasive > change to fix this issue, considering that it should be back-ported. > > I see two ways to implement this: > > 1. ForeignScanState->conn points to a ConnCacheEntry and it access the > PGConn via ConnCacheEntry->conn, so it can check if != NULL before using. > > 2. Make pgfdw_reject_incomplete_xact_state_change() or > disconnect_pg_server() receive a PgFdwConnState and add a new field on > this state to represent that the connection is closed and them check > this field on the proper code paths. > > With the patch proposed on the previous email the server don't crash > and any use of PgFdwScanState->conn will make the command to fail with > something like this: > > ERROR: 08006: no connection to the server > CONTEXT: remote SQL command: CLOSE c1 > LOCATION: pgfdw_report_internal, connection.c:1059 > > > So I don't think that this change would be worth, or I'm missing > something? What do you think?
I don't feel the need to do these, either, for the reason mentioned upthread. Thanks again! Best regards, Etsuro Fujita
