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