Thread

Commits

  1. doc: fix reference for finding replication slots to drop

  1. Doubt on content under Routine Vacuuming section

    The Post Office <noreply@postgresql.org> — 2026-01-06T04:11:20Z

    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.
    
  2. Re: Doubt on content under Routine Vacuuming section

    Laurenz Albe <laurenz.albe@cybertec.at> — 2026-01-06T09:53:34Z

    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
    
  3. Re: Doubt on content under Routine Vacuuming section

    Robert Treat <rob@xzilla.net> — 2026-01-08T04:36:07Z

    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
    
    
    
    
  4. Re: Doubt on content under Routine Vacuuming section

    Fujii Masao <masao.fujii@gmail.com> — 2026-06-11T14:28:53Z

    On Thu, Jan 8, 2026 at 1:36 PM Robert Treat <rob@xzilla.net> wrote:
    > +1 on the fix, and the adding of the structname's.
    
    LGTM.
    
    
    > Given the commit that introduced this was backpatched to v14, ISTM
    > this should probably be backpatched as well.
    
    Barring any objections, I will commit the patch and backpatch it to v14.
    
    Regards,
    
    -- 
    Fujii Masao
    
    
    
    
  5. Re: Doubt on content under Routine Vacuuming section

    Fujii Masao <masao.fujii@gmail.com> — 2026-06-12T02:14:35Z

    On Thu, Jun 11, 2026 at 11:28 PM Fujii Masao <masao.fujii@gmail.com> wrote:
    >
    > On Thu, Jan 8, 2026 at 1:36 PM Robert Treat <rob@xzilla.net> wrote:
    > > +1 on the fix, and the adding of the structname's.
    >
    > LGTM.
    >
    >
    > > Given the commit that introduced this was backpatched to v14, ISTM
    > > this should probably be backpatched as well.
    >
    > Barring any objections, I will commit the patch and backpatch it to v14.
    
    I've pushed the patch. Thanks!
    
    Regards,
    
    -- 
    Fujii Masao