Update outdated references to SLRU ControlLock
Hi,
I just noticed that some references so the now removed SLRU ControlLock were
still present in slru.[ch]. I tried to improve the situation with the attached
patch by using the new "bank control lock" name that is used nearby.
Note that the main comment of slru.c still has one paragraph that mentions
"bank control lock" consistently before switching to just "control lock" in the
next paragraph. I'm assuming that it's ok in that context as it seems clear to
me that those are the same thing, just spelled with a less verbose name.
Attachments:
0001-Update-outdated-references-to-SLRU-ControlLock.patchtext/plain; charset=us-asciiDownload
From 8171ed0a87d998bd07dad6700bee0938b9fa49d9 Mon Sep 17 00:00:00 2001
From: Julien Rouhaud <julien.rouhaud@free.fr>
Date: Mon, 1 Sep 2025 11:16:01 +0800
Subject: [PATCH] Update outdated references to SLRU ControlLock
Oversight in 53c2a97a9266 which removed the single ControlLock and added the
bank control locks.
---
src/backend/access/transam/slru.c | 8 ++++----
src/include/access/slru.h | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/backend/access/transam/slru.c b/src/backend/access/transam/slru.c
index 10ec259f382..f78e35d66d5 100644
--- a/src/backend/access/transam/slru.c
+++ b/src/backend/access/transam/slru.c
@@ -401,9 +401,9 @@ SimpleLruZeroPage(SlruCtl ctl, int64 pageno)
* Assume this page is now the latest active page.
*
* Note that because both this routine and SlruSelectLRUPage run with
- * ControlLock held, it is not possible for this to be zeroing a page that
- * SlruSelectLRUPage is going to evict simultaneously. Therefore, there's
- * no memory barrier here.
+ * bank control lock held, it is not possible for this to be zeroing a
+ * page that SlruSelectLRUPage is going to evict simultaneously.
+ * Therefore, there's no memory barrier here.
*/
pg_atomic_write_u64(&shared->latest_page_number, pageno);
@@ -437,7 +437,7 @@ SimpleLruZeroLSNs(SlruCtl ctl, int slotno)
* This is a convenience wrapper for the common case of zeroing a page and
* immediately flushing it to disk.
*
- * Control lock is acquired and released here.
+ * Bank control lock is acquired and released here.
*/
void
SimpleLruZeroAndWritePage(SlruCtl ctl, int64 pageno)
diff --git a/src/include/access/slru.h b/src/include/access/slru.h
index 20dbd1e0070..0b81bc62639 100644
--- a/src/include/access/slru.h
+++ b/src/include/access/slru.h
@@ -55,7 +55,7 @@ typedef enum
/*
* Shared-memory state
*
- * ControlLock is used to protect access to the other fields, except
+ * Bank control locks are used to protect access to the other fields, except
* latest_page_number, which uses atomics; see comment in slru.c.
*/
typedef struct SlruSharedData
--
2.51.0
On Mon, Sep 01, 2025 at 11:32:41AM +0800, Julien Rouhaud wrote:
Note that the main comment of slru.c still has one paragraph that mentions
"bank control lock" consistently before switching to just "control lock" in the
next paragraph. I'm assuming that it's ok in that context as it seems clear to
me that those are the same thing, just spelled with a less verbose name.
Good catch, right.
I am not seeing "control" used much as a term (3 times on HEAD).
There is a lot of "bank lock" or "SLRU bank lock", both being mixed
depending on the parts of the code using SLRUs (multixact, predicates,
etc.).
"SLRU bank lock" speaks a bit better to me, as the concept relates
to.. SLRUs, but that's mostly a matter of taste between the three
wordings, I guess. Do you have a preference?
Not saying that one is better than the other as they're all used, just
noticed the difference in the comments, with all the terms referring
to the same thing.
--
Michael
On Mon, Sep 01, 2025 at 02:05:56PM +0900, Michael Paquier wrote:
On Mon, Sep 01, 2025 at 11:32:41AM +0800, Julien Rouhaud wrote:
Note that the main comment of slru.c still has one paragraph that mentions
"bank control lock" consistently before switching to just "control lock" in the
next paragraph. I'm assuming that it's ok in that context as it seems clear to
me that those are the same thing, just spelled with a less verbose name.Good catch, right.
I am not seeing "control" used much as a term (3 times on HEAD).
There is a lot of "bank lock" or "SLRU bank lock", both being mixed
depending on the parts of the code using SLRUs (multixact, predicates,
etc.).
Yes, and some other parts simply mentions "lock" (eg TransactionIdGetStatus)
"SLRU bank lock" speaks a bit better to me, as the concept relates
to.. SLRUs, but that's mostly a matter of taste between the three
wordings, I guess. Do you have a preference?
I don't really have a preference. Bank lock is shorter but may be a bit more
obscure, especially outside slru.c, so using "SLRU bank lock" could be better
indeed.
On Mon, Sep 01, 2025 at 01:19:41PM +0800, Julien Rouhaud wrote:
I don't really have a preference. Bank lock is shorter but may be a bit more
obscure, especially outside slru.c, so using "SLRU bank lock" could be better
indeed.
Okay, I have used "SLRU bank lock" and backpatched that down to v17
where it matters.
--
Michael
On Wed, Sep 03, 2025 at 10:21:54AM +0900, Michael Paquier wrote:
On Mon, Sep 01, 2025 at 01:19:41PM +0800, Julien Rouhaud wrote:
I don't really have a preference. Bank lock is shorter but may be a bit more
obscure, especially outside slru.c, so using "SLRU bank lock" could be better
indeed.Okay, I have used "SLRU bank lock" and backpatched that down to v17
where it matters.
Thanks a lot!
Hi,
On Wed, Sep 03, 2025 at 10:22:37AM +0800, Julien Rouhaud wrote:
On Wed, Sep 03, 2025 at 10:21:54AM +0900, Michael Paquier wrote:
Okay, I have used "SLRU bank lock" and backpatched that down to v17
where it matters.
I caught a couple of other minor outdated things in the comments when finishing
rebasing my own work:
- long_segment_names has been added to SimpleLruInit
- SlruRecentlyUsed is not a macro anymore
Simple patch attached.
Attachments:
0001-Fix-a-few-outdated-SLRU-comments.patchtext/plain; charset=us-asciiDownload
From 392e74d26fdab34d1c3ed87cca58f06c92754d0b Mon Sep 17 00:00:00 2001
From: Julien Rouhaud <julien.rouhaud@free.fr>
Date: Fri, 5 Sep 2025 09:04:58 +0800
Subject: [PATCH] Fix a few outdated SLRU comments
long_segment_names has been added to SimpleLruInit, and SlruRecentlyUsed is now
a (static inline) function.
---
src/backend/access/transam/slru.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/backend/access/transam/slru.c b/src/backend/access/transam/slru.c
index f78e35d66d5..7ef52a6da0f 100644
--- a/src/backend/access/transam/slru.c
+++ b/src/backend/access/transam/slru.c
@@ -246,6 +246,7 @@ SimpleLruAutotuneBuffers(int divisor, int max)
* buffer_tranche_id: tranche ID to use for the SLRU's per-buffer LWLocks.
* bank_tranche_id: tranche ID to use for the bank LWLocks.
* sync_handler: which set of functions to use to handle sync requests
+ * long_segment_names: use short or long segment names
*/
void
SimpleLruInit(SlruCtl ctl, const char *name, int nslots, int nlsns,
@@ -644,7 +645,7 @@ SimpleLruReadPage_ReadOnly(SlruCtl ctl, int64 pageno, TransactionId xid)
shared->page_number[slotno] == pageno &&
shared->page_status[slotno] != SLRU_PAGE_READ_IN_PROGRESS)
{
- /* See comments for SlruRecentlyUsed macro */
+ /* See comments for SlruRecentlyUsed() */
SlruRecentlyUsed(shared, slotno);
/* update the stats counter of pages found in the SLRU */
--
2.51.0
On Fri, Sep 05, 2025 at 09:47:24AM +0800, Julien Rouhaud wrote:
I caught a couple of other minor outdated things in the comments when finishing
rebasing my own work:- long_segment_names has been added to SimpleLruInit
- SlruRecentlyUsed is not a macro anymore
Right. The source of each mistake is different, both affect v17~.
Applied.
--
Michael
On Fri, Sep 05, 2025 at 02:11:18PM +0900, Michael Paquier wrote:
On Fri, Sep 05, 2025 at 09:47:24AM +0800, Julien Rouhaud wrote:
I caught a couple of other minor outdated things in the comments when finishing
rebasing my own work:- long_segment_names has been added to SimpleLruInit
- SlruRecentlyUsed is not a macro anymoreRight. The source of each mistake is different, both affect v17~.
Applied.
Thanks!