On 04/06/18 20:19, Chapman Flack wrote: > On 04/06/18 19:52, Andres Freund wrote: >> Wouldn't it be a better idea not to have a list there, that's guaranteed >> to get out of date? > > That might look like this, then. > > But I'm not sure how bad it is to have a list. How often does ResourceOwner > get taught a new type? It took nine years to grow these last three.
It also seemed worth documenting that the release callbacks are called for *every* ResourceOwnerRelease, but can consult CurrentResourceOwner to learn what owner is really being released. -Chap
>From 6541f1b5c28ede3bf0e88bb34d6a4eedc5731cab Mon Sep 17 00:00:00 2001 From: Chapman Flack <c...@anastigmatix.net> Date: Fri, 6 Apr 2018 21:08:02 -0400 Subject: [PATCH] Update README for Resource Owners. Built-in support for three more categories of owned object has accreted without mention in the README. Also explain that the release callbacks are global, and can consult CurrentResourceOwner to determine the owner being released. --- src/backend/utils/resowner/README | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/src/backend/utils/resowner/README b/src/backend/utils/resowner/README index 2998f6b..5049e7c 100644 --- a/src/backend/utils/resowner/README +++ b/src/backend/utils/resowner/README @@ -61,12 +61,20 @@ ResourceOwner transfers lock ownership to the parent instead of actually releasing the lock, if isCommit is true. 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. +several types of resource managed in the core, with the three operations +ResourceOwnerEnlarge<Foo>Refs(), ResourceOwnerRemember<Foo>Ref(), and +ResourceOwnerForget<Foo>Ref() for each type. The first ensures there is room +for at least one more entry of the type, and is separate from Remember... +so that out-of-memory can be detected before the resource is acquired. + +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. +Such callbacks are registered globally, not to a specific ResourceOwner, and +will be called during every ResourceOwnerRelease; to determine which owner is +being released, they can refer to CurrentResourceOwner, which points to it +while the callbacks are invoked. Whenever we are inside a transaction, the global variable CurrentResourceOwner shows which resource owner should be assigned -- 2.7.3
