Minor Improvements to pg_buffercache documentation

2025-07-02 Thread Fujii Masao

Hi,

While reading commit 8eede2c7200 and the pg_buffercache docs,
I noticed a few minor issues:

- There are missing index entries for pg_buffercache_numa() and
  pg_buffercache_usage_counts(), even though other functions have them.
- The section titles for pg_buffercache_evict_relation and
  pg_buffercache_evict_all are missing parentheses, unlike the others.

The attached patch addresses these points by:

- Adding index entries for pg_buffercache_numa() and
  pg_buffercache_usage_counts().
- Making the function section titles consistent by including parentheses
  where they were missing.

Also, a quick note on pg_buffercache_numa_pages(): although there's
an index entry for pg_buffercache_pages(), I didn't add one for
pg_buffercache_numa_pages() because both functions are typically accessed
via views, not directly. Regarding those functions, it seems enough to
have index entries for the views. So, it might make more sense to remove
the existing index entry for pg_buffercache_pages() for consistency.

BTW, all current index entries point to the top of the pg_buffercache
docs. Would it be better if each entry pointed directly to its relevant
section using a zone attribute like this?

- 
+ 
   pg_buffercache_summary
  

Thought?

Regards,

--
Fujii Masao
NTT DATA Japan Corporation
From 06013d1d1fbaa64aa99f5067b2608ab833a92b3d Mon Sep 17 00:00:00 2001
From: Fujii Masao 
Date: Thu, 3 Jul 2025 00:35:44 +0900
Subject: [PATCH v1] doc: Add missing index entries and fix title formatting in
 pg_buffercache docs.

This commit adds missing index entries for the functions pg_buffercache_numa()
and pg_buffercache_usage_counts() in the pg_buffercache documentation.

It also makes the function titles consistent by adding parentheses after
function names where they were previously missing.
---
 doc/src/sgml/pgbuffercache.sgml | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/doc/src/sgml/pgbuffercache.sgml b/doc/src/sgml/pgbuffercache.sgml
index 546ace8369e..eeb85a0e049 100644
--- a/doc/src/sgml/pgbuffercache.sgml
+++ b/doc/src/sgml/pgbuffercache.sgml
@@ -19,10 +19,18 @@
   pg_buffercache_pages
  
 
+ 
+  pg_buffercache_numa
+ 
+
  
   pg_buffercache_summary
  
 
+ 
+  pg_buffercache_usage_counts
+ 
+
  
   pg_buffercache_evict
  
@@ -489,7 +497,7 @@
  
 
  
-  The pg_buffercache_evict_relation 
Function
+  The pg_buffercache_evict_relation() 
Function
   
The pg_buffercache_evict_relation() function is very
similar to the pg_buffercache_evict() function.  The
@@ -507,7 +515,7 @@
  
 
  
-  The pg_buffercache_evict_all Function
+  The pg_buffercache_evict_all() 
Function
   
The pg_buffercache_evict_all() function is very
similar to the pg_buffercache_evict() function.  The
-- 
2.49.0



Re: Mention idle_replication_slot_timeout in pg_replication_slots docs

2025-07-02 Thread Fujii Masao



On 2025/07/01 13:52, Nisha Moond wrote:

On Mon, Jun 30, 2025 at 6:12 PM Fujii Masao  wrote:

Is this true starting from v16, when logical replication from standby was 
introduced?
In other words, in v15 and earlier, only max_slot_wal_keep_size could cause
the wal_status to become "unreserved" or "lost"? I'm wondering where to 
back-patch
this fix to.



I also think we should back-patch this till v16, since that’s when
additional slot invalidation causes were also introduced(commit
be87200). And since then “max_slot_wal_keep_size” is no longer the
sole reason for “unreserved” or “lost” status.


Okay, I've prepared two patches:

- 0001 removes the incorrect line: "If restart_lsn is NULL, this field is null."
  This should be back-patched to v13.
- 0002 updates the description of the wal_status to reflect that 
max_slot_wal_keep_size
  is not the only cause of the lost state. This should be back-patched to v16.

Barrng objections, I will commit these patches.

Regards,

--
Fujii Masao
NTT DATA Japan Corporation
From d8b9c1aace3f21bc916d905380894376bb3c7a6f Mon Sep 17 00:00:00 2001
From: Fujii Masao 
Date: Wed, 2 Jul 2025 15:37:53 +0900
Subject: [PATCH v3 1/2] doc: Remove incorrect note about wal_status in
 pg_replication_slots.

The documentation previously stated that the wal_status column is NULL
if restart_lsn is NULL in the pg_replication_slots view. This is incorrect,
and wal_status can be "lost" even when restart_lsn is NULL.

This commit removes the incorrect description.

Back-patched to all supported versions.

Author: Fujii Masao 
Reviewed-by: Nisha Moond 
Discussion: 
https://postgr.es/m/c9d23cdc-b5dd-455a-8ee9-f1f24d701...@oss.nttdata.com
Backpatch-through: 13
---
 doc/src/sgml/system-views.sgml | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml
index 986ae1f543d..82825db03bb 100644
--- a/doc/src/sgml/system-views.sgml
+++ b/doc/src/sgml/system-views.sgml
@@ -2832,8 +2832,7 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx

The last two states are seen only when
 is
-   non-negative. If restart_lsn is NULL, this
-   field is null.
+   non-negative.
   
  
 
-- 
2.49.0

From 320e208e4443eb2c89f777ef990f6653628589b4 Mon Sep 17 00:00:00 2001
From: Fujii Masao 
Date: Wed, 2 Jul 2025 16:02:29 +0900
Subject: [PATCH v3 2/2] doc: Update outdated descriptions of wal_status in
 pg_replication_slots.

The documentation for pg_replication_slots previously mentioned only
max_slot_wal_keep_size as a condition under which the wal_status column
could show unreserved or lost. However, since commit be87200,
replication slots can also be invalidated due to horizon or wal_level,
and since commit ac0e33136ab, idle_replication_slot_timeout can also
trigger this state.

This commit updates the description of the wal_status column to
reflect that max_slot_wal_keep_size is not the only cause of the lost state.

Back-patched to v16, where the additional invalidation cases were introduced.

Author: Fujii Masao 
Reviewed-by: Hayato Kuroda 
Reviewed-by: Nisha Moond 
Discussion: 
https://postgr.es/m/78b34e84-2195-4f28-a151-5d204a382...@oss.nttdata.com
Backpatch-through: 17
---
 doc/src/sgml/system-views.sgml | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml
index 82825db03bb..e1ac544ee40 100644
--- a/doc/src/sgml/system-views.sgml
+++ b/doc/src/sgml/system-views.sgml
@@ -2819,20 +2819,18 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts 
ppx
  
   unreserved means that the slot no longer
   retains the required WAL files and some of them are to be removed at
-  the next checkpoint.  This state can return
+  the next checkpoint.  This typically occurs when
+   is set to
+  a non-negative value.  This state can return
   to reserved or extended.
  
 
 
  
-  lost means that some required WAL files have
-  been removed and this slot is no longer usable.
+  lost means that this slot is no longer usable.
  
 

-   The last two states are seen only when
-is
-   non-negative.
   
  
 
-- 
2.49.0