On Tue, Aug 11, 2020 at 8:45 AM Li Japin <japi...@hotmail.com> wrote: > > I’ve attached a new version that add “idle_session_timeout” in the default > postgresql.conf. >
Hi, I would like to just mention a use case I thought of while discussing [1]: In postgres_fdw: assuming we use idle_in_session_timeout on remote backends, the remote sessions will be closed after timeout, but the locally cached connection cache entries still exist and become stale. The subsequent queries that may use the cached connections will fail, of course these subsequent queries can retry the connections only at the beginning of a remote txn but not in the middle of a remote txn, as being discussed in [2]. For instance, in a long running local txn, let say we used a remote connection at the beginning of the local txn(note that it will open a remote session and it's entry is cached in local connection cache), only we use the cached connection later at some point in the local txn, by then let say the idle_in_session_timeout has happened on the remote backend and the remote session would have been closed, the long running local txn will fail instead of succeeding. I think, since the idle_session_timeout is by default disabled, we have no problem. My thought is what if a user enables the feature(knowingly or unknowingly) on the remote backend? If the user knows about the above scenario, that may be fine. On the other hand, either we can always the feature on the remote backend(at the beginning of the remote txn, like we set for some other configuration settings see - configure_remote_session() in connection.c) or how about mentioning the above scenario in this feature documentation? [1] - https://www.postgresql.org/message-id/CALj2ACU1NBQo9mihA15dFf6udkOi7m0u2_s5QJ6dzk%3DZQyVbwQ%40mail.gmail.com [2] - https://www.postgresql.org/message-id/flat/CALj2ACUAi23vf1WiHNar_LksM9EDOWXcbHCo-fD4Mbr1d%3D78YQ%40mail.gmail.com With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com
