Re: Add Postgres module info
Andrei Lepikhov <lepihov@gmail.com>
From: Andrei Lepikhov <lepihov@gmail.com>
To: Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Euler Taveira <euler@eulerto.com>, Andres Freund <andres@anarazel.de>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-12-12T04:35:56Z
Lists: pgsql-hackers
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. -- regards, Andrei Lepikhov
Commits
-
Avoid mixing designated and non-designated field initializers.
- d66997dfe8fe 18.0 landed
-
Use PG_MODULE_MAGIC_EXT in our installable shared libraries.
- 55527368bd07 18.0 landed
-
Introduce PG_MODULE_MAGIC_EXT macro.
- 9324c8c58065 18.0 landed