Re: Add Postgres module info - Mailing list pgsql-hackers

From Andrei Lepikhov
Subject Re: Add Postgres module info
Date
Msg-id a0872eec-1596-466f-8e15-0540a29528c4@gmail.com
Whole thread Raw
In response to Re: Add Postgres module info  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Add Postgres module info
List 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 by date:

Previous
From: vignesh C
Date:
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation
Next
From: Amit Kapila
Date:
Subject: Re: Skip collecting decoded changes of already-aborted transactions