Hello. At Mon, 17 Aug 2020 19:28:10 +0530, Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote in > On Fri, Aug 14, 2020 at 1:32 PM Li Japin <japi...@hotmail.com> wrote: > > > > On Aug 14, 2020, at 2:15 PM, Bharath Rupireddy < > bharath.rupireddyforpostg...@gmail.com> wrote: > > > > 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? > > > > Though we can disable the idle_session_timeout when using postgres_fdw, > > there still has locally cached connection cache entries when the remote > sessions > > terminated by accident. AFAIK, you have provided a patch to solve this > > problem, and it is in current CF [1]. > > > > [1] - https://commitfest.postgresql.org/29/2651/ > > > > Yes, that solution can retry the cached connections at only the beginning > of the remote txn and not at the middle of the remote txn and that makes > sense as we can not retry connecting to a different remote backend in the > middle of a remote txn. > > +1 for disabling the idle_session_timeout feature in case of postgres_fdw. > This can avoid the remote backends to timeout during postgres_fdw usages.
The same already happens for idle_in_transaction_session_timeout and we can use "ALTER ROLE/DATABASE SET" to dislable or loosen them, it's a bit cumbersome, though. I don't think we should (at least implicitly) disable those timeouts ad-hockerly for postgres_fdw. regards. -- Kyotaro Horiguchi NTT Open Source Software Center