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

On 2020-11-25 06:17, Bharath Rupireddy wrote:
> On Wed, Nov 25, 2020 at 7:24 AM Craig Ringer
> <craig.ringer@enterprisedb.com> wrote:
>> 
>> A quick thought here.
>> 
>> Would it make sense to add a hook in the DISCARD ALL implementation 
>> that postgres_fdw can register for?
>> 
>> There's precedent here, since DISCARD ALL already has the same effect 
>> as SELECT pg_advisory_unlock_all(); amongst other things.
>> 
> 
> IIUC, then it is like a core(server) function doing some work for the
> postgres_fdw module. Earlier in the discussion, one point raised was
> that it's better not to have core handling something related to
> postgres_fdw. This is the reason we have come up with postgres_fdw
> specific function and a GUC, which get defined when extension is
> created. Similarly, dblink also has it's own bunch of functions one
> among them is dblink_disconnect().
> 

If I have got Craig correctly, he proposed that we already have a 
DISCARD ALL statement, which is processed by DiscardAll(), and it 
releases internal resources known from the core perspective. That way, 
we can introduce a general purpose hook DiscardAll_hook(), so 
postgres_fdw can get use of it to clean up its own resources 
(connections in our context) if needed. In other words, it is not like a 
core function doing some work for the postgres_fdw module, but rather 
like a callback/hook, that postgres_fdw is able to register to do some 
additional work.

It can be a good replacement for 0001, but won't it be already an 
overkill to drop all local caches along with remote connections? I mean, 
that it would be a nice to have hook from the extensibility perspective, 
but postgres_fdw_disconnect() still makes sense, since it does a very 
narrow and specific job.


Regards
-- 
Alexey Kondratov

Postgres Professional https://www.postgrespro.com
Russian Postgres Company