Thanks for looking.
On Tue, Sep 14, 2021 at 9:17 AM Michael Paquier <michael@paquier.xyz> wrote:
> 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/.
Oops.
> 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).
Yeah, that might be better.
Patch updated. Given the new text, I thought it might be better to
move the paragraph right next to the description of the ResourceOwner
API at the beginning of the section, because the context seems clearer
that way. Thoughts?
--
Amit Langote
EDB: http://www.enterprisedb.com
