Hi,
On 2024-12-12 11:35:56 +0700, Andrei Lepikhov wrote:
> On 12/12/24 10:44, Michael Paquier wrote:
> > On Wed, Dec 11, 2024 at 10:39:38PM -0500, Tom Lane wrote:
> > > Michael Paquier <michael@paquier.xyz> writes:
> > > > Presumably,
> > > > the extra tracking can be done in dfmgr.c with more fields added to
> > > > DynamicFileList to track the information involved.
> > >
> > > I wouldn't add any overhead to the normal case for this. Couldn't
> > > we walk the list and re-fetch each module's magic block inside
> > > this new function?
> >
> > Depends on how much we should try to cache to make that less expensive
> > on repeated calls because we cannot unload libraries, but sure, I
> > don't see why we could not that for each SQL function call to simplify
> > the logic and the structures in place.
> I want to say that 'cannot unload libraries' is a negative outcome of the
> architecture. It would be better to invent something like PG_unregister,
> allowing libraries to at least return a hook routine call back to the
> system.
> So, maybe it makes sense to design this feature with re-fetching libraries,
> supposing it is already implemented somehow and elements of the
> DynamicFileList may be removed.
I am quite certain we'll not support unloading libraries anytime soon. We used
to support it and it caused problems... Changing anything about how exactly
things are tracked in dfmgr.c will be the smallest part of supporting
unloading libraries again.
Greetings,
Andres Freund
