Doubt on content under Routine Vacuuming section
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/18/routine-vacuuming.html
Description:
Hi All,
Doc ref:
https://www.postgresql.org/docs/current/routine-vacuuming.html#ROUTINE-VACUUMING
There are five points under this section;
"In this condition any transactions already in progress can continue, but
only read-only transactions can be started. Operations that modify database
records or truncate relations will fail. The VACUUM command can still be run
normally. Note that, contrary to what was sometimes recommended in earlier
releases, it is not necessary or desirable to stop the postmaster or enter
single user-mode in order to restore normal operation. Instead, follow these
steps:..."
In the third point it says "Use pg_stat_replication to find slots where
age(xmin) or age(catalog_xmin) is large. In many cases, such slots were
created for replication to servers that no longer exist, or that have been
down for a long time."
However, those columns, ie: xmin and catalog_xmin exists in
pg_replication_slots metadata view. :
https://www.postgresql.org/docs/18/view-pg-replication-slots.html
Not in the pg_stat_replication.
Please check if my observation is correct or not.
Thanks.
On Tue, 2026-01-06 at 04:11 +0000, PG Doc comments form wrote:
https://www.postgresql.org/docs/current/routine-vacuuming.html#ROUTINE-VACUUMING
There are five points under this section;
"In this condition any transactions already in progress can continue, but
only read-only transactions can be started. Operations that modify database
records or truncate relations will fail. The VACUUM command can still be run
normally. Note that, contrary to what was sometimes recommended in earlier
releases, it is not necessary or desirable to stop the postmaster or enter
single user-mode in order to restore normal operation. Instead, follow these
steps:..."In the third point it says "Use pg_stat_replication to find slots where
age(xmin) or age(catalog_xmin) is large. In many cases, such slots were
created for replication to servers that no longer exist, or that have been
down for a long time."
However, those columns, ie: xmin and catalog_xmin exists in
pg_replication_slots metadata view. :
https://www.postgresql.org/docs/18/view-pg-replication-slots.html
Not in the pg_stat_replication.Please check if my observation is correct or not.
You are correct. Attached is a patch that fixes the documentation.
Yours,
Laurenz Albe
Attachments:
v1-0001-Fix-doc-for-recovering-from-approaching-xid-wrapa.patchtext/x-patch; charset=UTF-8; name=v1-0001-Fix-doc-for-recovering-from-approaching-xid-wrapa.patchDownload+3-4
On Tue, Jan 6, 2026 at 4:53 AM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
On Tue, 2026-01-06 at 04:11 +0000, PG Doc comments form wrote:
https://www.postgresql.org/docs/current/routine-vacuuming.html#ROUTINE-VACUUMING
There are five points under this section;
"In this condition any transactions already in progress can continue, but
only read-only transactions can be started. Operations that modify database
records or truncate relations will fail. The VACUUM command can still be run
normally. Note that, contrary to what was sometimes recommended in earlier
releases, it is not necessary or desirable to stop the postmaster or enter
single user-mode in order to restore normal operation. Instead, follow these
steps:..."In the third point it says "Use pg_stat_replication to find slots where
age(xmin) or age(catalog_xmin) is large. In many cases, such slots were
created for replication to servers that no longer exist, or that have been
down for a long time."
However, those columns, ie: xmin and catalog_xmin exists in
pg_replication_slots metadata view. :
https://www.postgresql.org/docs/18/view-pg-replication-slots.html
Not in the pg_stat_replication.Please check if my observation is correct or not.
You are correct. Attached is a patch that fixes the documentation.
+1 on the fix, and the adding of the structname's.
Given the commit that introduced this was backpatched to v14, ISTM
this should probably be backpatched as well.
Robert Treat
https://xzilla.net