Hasn't been updated as built-in support grew for temp files, DSM segments, and JIT contexts.
With enough luck, a README update won't break anything. -Chap
>From fb06e17916ad6b445b1cf6361de6a7f2749ea225 Mon Sep 17 00:00:00 2001 From: Chapman Flack <c...@anastigmatix.net> Date: Fri, 6 Apr 2018 19:41:57 -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 | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/src/backend/utils/resowner/README b/src/backend/utils/resowner/README index 2998f6b..b65fdb8 100644 --- a/src/backend/utils/resowner/README +++ b/src/backend/utils/resowner/README @@ -61,12 +61,13 @@ 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. +buffer pins, lmgr locks, and catcache, relcache, plancache, tupdesc, snapshot, +open temporary file, dynamic shared memory segment, and JIT context 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. Whenever we are inside a transaction, the global variable CurrentResourceOwner shows which resource owner should be assigned -- 2.7.3
