Обсуждение: resowner module README needs update?

Hi,

I was reading src/backend/utils/resowner/README today and noticed the
following paragraph that mentions the types of objects/resources
*directly* supported by the module.

===
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.
===

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.

-- 
Amit Langote
EDB: http://www.enterprisedb.com

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

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

On Tue, Sep 14, 2021 at 12:18:21PM +0900, Amit Langote wrote:
> 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?

No objections here.
--
Michael

On Tue, Sep 14, 2021 at 07:37:28PM +0900, Michael Paquier wrote:
> No objections here.

Done as of cae6fc2.
--
Michael

On Wed, Sep 15, 2021 at 4:09 PM Michael Paquier <michael@paquier.xyz> wrote:
> On Tue, Sep 14, 2021 at 07:37:28PM +0900, Michael Paquier wrote:
> > No objections here.
>
> Done as of cae6fc2.

Thank you.

-- 
Amit Langote
EDB: http://www.enterprisedb.com