On Mon, Sep 13, 2021 at 10:44:11PM +0900, Amit Langote wrote: > It seems a bunch of other object/resource types have been integrated > into the resowner mechanism since the list was last updated (2008). > > Attached patch updates the list. Not sure though if we should keep > the current format of the list, which after updating becomes a bit too > long.
Currently, ResourceOwners contain direct support for recording ownership of -buffer pins, lmgr locks, and catcache, relcache, plancache, tupdesc, and -snapshot references. Other objects can be associated with a ResourceOwner by -recording the address of the owning ResourceOwner in such an object. There is -an API for other modules to get control during ResourceOwner release, so that -they can scan their own data structures to find the objects that need to be -deleted. +buffer pins, lmgr locks, and catcache, relcache, plancache, tupdesc, snapshot +references, temporary files, dynamic shared memory segments, JIT contexts, +cryptohash contexts, and HMAX contexts. Other objects can be associated with +a ResourceOwner by recording the address of the owning ResourceOwner in such +an object. There is an API for other modules to get control during +ResourceOwner release, so that they can scan their own data structures to find +the objects that need to be deleted. s/HMAX/HMAC/. Just updating this list is a recipe for having it out-of-sync again. What about instead redirecting users to look at ResourceOwnerData in resowner.c about the types of resources owners that exist? I would suggest something like that: "Currently, ResourceOwners contain direct support for various built-in types (see ResourceOwnerData in src/backend/utils/resowner/resowner.c). -- Michael
signature.asc
Description: PGP signature
