On 04/06/18 19:52, Andres Freund wrote: > On 2018-04-06 19:46:25 -0400, Chapman Flack wrote: >> 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. > > 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. -Chap
>From 56c047c5fa963c0c22affdde2ce669ed88693e5a Mon Sep 17 00:00:00 2001 From: Chapman Flack <c...@anastigmatix.net> 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 +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. Whenever we are inside a transaction, the global variable CurrentResourceOwner shows which resource owner should be assigned -- 2.7.3
