On 2020-11-25 06:17, Bharath Rupireddy wrote:
On Wed, Nov 25, 2020 at 7:24 AM Craig Ringer
<craig.rin...@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
