Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
Cc: Alexey Kondratov <a(dot)kondratov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit
Date: 2020-12-17 11:13:18
Message-ID: CALj2ACXghAf_GPOVBVuvuPy=9b5ccB7mtf1Jeeoa0QMav-cxOQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 14, 2020 at 11:13 PM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> On Mon, Dec 14, 2020 at 11:00 PM Fujii Masao
> <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
> > > One more point for the above scenario: if the user mapping is dropped
> > > in another session, then cache lookup for that entry in the
> > > postgres_fdw_get_connections() returns a null tuple which I plan to
> > > not throw an error, but just to skip in that case and continue. But if
> > > the user mapping is not dropped in another session but altered, then
> > > postgres_fdw_get_connections() still can show that in the output.
> >
> > Yes, so *if* we really want to return even connection invalidated by drop of
> > user mapping, the cached connection entry may need to store not only
> > user mapping id but also server id so that we can get the server name without
> > user mapping entry.
>
> We can do that, but what happens if the foreign server itself get
> dropped with cascade option in another session, use case is as
> follows:
>
> 1) Run a foreign query in session 1 with server 1, user mapping 1
> 2) Try to drop foreign server 1, then we would not be allowed to do so
> because of dependency, if we use CASCADE, then the dependent user
> mapping 1 and foreign tables get dropped too.
> 3) Run the postgres_fdw_get_connections(), at the start of txn, the
> cached entry gets invalidated via pgfdw_inval_callback() and we try to
> use the stored server id of the invalid entry (for which the foreign
> server would have been dropped) and lookup in sys catalogues, so again
> a null tuple is returned.

Hi,

Any further thoughts on this would be really helpful.

Discussion here is on the point - whether to show up the invalidated
connections in the output of the new postgres_fdw_get_connections()
function? If we were to show, then because of the solution we proposed
for the connection leak problem in [1], will the invalidated entries
be shown every time?

[1] - https://www.postgresql.org/message-id/flat/CALj2ACVNcGH_6qLY-4_tXz8JLvA%2B4yeBThRfxMz7Oxbk1aHcpQ%40mail.gmail.com

With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hou, Zhijie 2020-12-17 12:08:41 RE: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit
Previous Message Bharath Rupireddy 2020-12-17 11:05:33 Re: New Table Access Methods for Multi and Single Inserts