[PATCH] Update README for Resource Owners
Started by Chapman Flackalmost 8 years ago4 messages
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
Attachments:
0001-Update-README-for-Resource-Owners.patchtext/x-patch; name=0001-Update-README-for-Resource-Owners.patchDownload
From fb06e17916ad6b445b1cf6361de6a7f2749ea225 Mon Sep 17 00:00:00 2001
From: Chapman Flack <chap@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
Re: [PATCH] Update README for Resource Owners
Hi,
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?
Greetings,
Andres Freund
Re: [PATCH] Update README for Resource Owners
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:
0001-Update-README-for-Resource-Owners-v2.patchtext/x-patch; name=0001-Update-README-for-Resource-Owners-v2.patchDownload
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/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
Re: [PATCH] Update README for Resource Owners
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
Attachments:
0001-Update-README-for-Resource-Owners-v3.patchtext/x-patch; name=0001-Update-README-for-Resource-Owners-v3.patchDownload
From 6541f1b5c28ede3bf0e88bb34d6a4eedc5731cab Mon Sep 17 00:00:00 2001
From: Chapman Flack <chap@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