Hello.
At Mon, 17 Aug 2020 19:28:10 +0530, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote in
> On Fri, Aug 14, 2020 at 1:32 PM Li Japin <japinli@hotmail.com> wrote:
> >
> > On Aug 14, 2020, at 2:15 PM, Bharath Rupireddy <
> bharath.rupireddyforpostgres@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
