From: Chapman Flack <chap@anastigmatix.net>
To: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH] Update README for Resource Owners
Date: Fri, 6 Apr 2018 20:19:28 -0400
Message-ID: <5AC80E90.5000407@anastigmatix.net> (raw)
In-Reply-To: <20180406235209.k2gfizjfi2xczo6z@alap3.anarazel.de>
References: <5AC806D1.1090608@anastigmatix.net>
<20180406235209.k2gfizjfi2xczo6z@alap3.anarazel.de>
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
Attachments:
[text/x-patch] 0001-Update-README-for-Resource-Owners-v2.patch (2.0K, ../5AC80E90.5000407@anastigmatix.net/2-0001-Update-README-for-Resource-Owners-v2.patch)
download | inline diff:
From 56c047c5fa963c0c22affdde2ce669ed88693e5a Mon Sep 17 00:00:00 2001
From: Chapman Flack <chap@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/READMEindex 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: chap@anastigmatix.net, andres@anarazel.de
Subject: Re: [PATCH] Update README for Resource Owners
In-Reply-To: <5AC80E90.5000407@anastigmatix.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox