From: Chapman Flack Date: Fri, 6 Apr 2018 20:16:42 -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. --- src/backend/utils/resowner/README | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/src/backend/utils/resowner/README b/src/backend/utils/resowner/README index 2998f6b..c01f3bc 100644 --- a/src/backend/utils/resowner/README +++ b/src/backend/utils/resowner/README @@ -61,12 +61,16 @@ 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 +ResourceOwnerEnlargeRefs(), ResourceOwnerRememberRef(), and +ResourceOwnerForgetRef() 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. Whenever we are inside a transaction, the global variable CurrentResourceOwner shows which resource owner should be assigned -- 2.7.3 --------------090105000607020506010908--