> However, if PGconn is NULL, it seems like postgres_fdw_get_connections() > wouldn't include that connection in the result. If the connection status > is not CONNECTION_OK, it looks like the connection would be closed by > pgfdw_reset_xact_state() before the local backend processes the query > calling postgres_fdw_get_connections(). So, can remote_backend_pid really > be NULL? I agree on this point with the current implementation of postgres_fdw. There can be different state of connection (PGconn) status like CONNECTION_OK, CONNECTION_BAD, CONNECTION_STARTED etc. Currently connect_pg_server makes sure to create connections with status CONNECTION_OK or abort current transaction if it fails. All other intermediate states are handled within the libpq library API libpqsrv_connect_params. So there is no way in the connection workflow to return connection with status other than CONNECTION_OK and we are safe here. There is a case where connection status can be set to CONNECTION_BAD if we failed to read the result. But in that case we invoke an error and abort the transaction. As you mentioned, pgfdw_reset_xact_state gets called in a transaction callback which will make sure to close the connection at the end of transaction. Again here also we look safe in the query execution workflow.
Only thing which bothers me is the asynchronous workflow. postgres_fdw uses libpq library and library provides mechanism to perform asynchronous API [1]. These asynchronous API's can set connection status to CONNECTION_BAD (during pqReadData). Currently postgres_fdw makes sure to close connections at the end of query if something fails. But let's say in the future we support SQL commands to initiate pipeline mode and retrieve data asynchronously.In this case we end up with CONNECTION_BAD status across query? Other states might also occur during (and only during) an asynchronous connection procedure. These indicate the current stage of the connection procedure and might be useful to provide feedback to the user for example. [1] - https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-PQCONNECTSTARTPARAMS -- Sagar Dilip Shedge, SDE AWS
