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

From Bharath Rupireddy
Subject Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit
Date
Msg-id CALj2ACU7QwViOwSFCejUGZvTWKhmHoXoXD0Egf9vtCNv36s+Uw@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit  (Craig Ringer <craig.ringer@enterprisedb.com>)
Responses Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit  (Alexey Kondratov <a.kondratov@postgrespro.ru>)
List pgsql-hackers
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
otherthings.
 
>

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().

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



pgsql-hackers by date:

Previous
From: Seino Yuki
Date:
Subject: Re: [PATCH] Add features to pg_stat_statements
Next
From: Michael Paquier
Date:
Subject: Re: Removal of currtid()/currtid2() and some table AM cleanup