Re: Add Postgres module info
От | Andrei Lepikhov |
---|---|
Тема | Re: Add Postgres module info |
Дата | |
Msg-id | a0872eec-1596-466f-8e15-0540a29528c4@gmail.com обсуждение исходный текст |
Ответ на | Re: Add Postgres module info (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Add Postgres module info
|
Список | 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
В списке pgsql-hackers по дате отправления: