Thread: 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
Attachment
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
Attachment
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
Attachment
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
Attachment
On Tue, Sep 14, 2021 at 07:37:28PM +0900, Michael Paquier wrote: > No objections here. Done as of cae6fc2. -- Michael
Attachment
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