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
