| From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
|---|---|
| To: | Craig Ringer <craig(dot)ringer(at)enterprisedb(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-11-25 03:17:52 |
| Message-ID: | CALj2ACU7QwViOwSFCejUGZvTWKhmHoXoXD0Egf9vtCNv36s+Uw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Nov 25, 2020 at 7:24 AM Craig Ringer
<craig(dot)ringer(at)enterprisedb(dot)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().
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2020-11-25 03:21:57 | Re: Removal of currtid()/currtid2() and some table AM cleanup |
| Previous Message | Seino Yuki | 2020-11-25 03:02:38 | Re: [PATCH] Add features to pg_stat_statements |