public inbox for [email protected]
help / color / mirror / Atom feedFrom: Shinya Kato <[email protected]>
To: Laurenz Albe <[email protected]>
Cc: Japin Li <[email protected]>
Cc: wenhui qiu <[email protected]>
Cc: Sami Imseih <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Report oldest xmin source when autovacuum cannot remove tuples
Date: Thu, 28 May 2026 14:34:54 +0900
Message-ID: <CAOzEurQsmFkf5_+z8ymj6kTdUF8qJBr8NAs02Ha1yUvJ0Amx_g@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAOzEurSgy-gDtwFmEbj5+R9PL0_G3qYB6nnzJtNStyuf87VSVg@mail.gmail.com>
<CAHGQGwFVdccfhN7PFHU5gZcMNdQuyL8DhZSks2FuuTcZ5V_pGQ@mail.gmail.com>
<CAGjGUAL-qZ6Na-cH4RY5raF4NwuF47ZVNyP0uMYQcks3w5b7Dw@mail.gmail.com>
<CAA5RZ0s+UUXekbeGcC-H71kW=MfeaUCOV=yEWX94NXViO2-=pA@mail.gmail.com>
<CAOzEurQVUsRa45aKdi1Qrc4wVsQKSmbLcN+2A9Eu1W1jm2Y5fw@mail.gmail.com>
<CAA5RZ0sjMgMo4Xg-niyyF-CpkQ_CK6uOfNKYT=9RmiBkAxQkbQ@mail.gmail.com>
<CAGjGUAJ8JVL9J32ChchmVLgZycEyXf-r-KHc5EiRM3LDiEoPtA@mail.gmail.com>
<CAOzEurTNVkvvscKeEOy0WwfzyqO+J_MyXwkjRteJ_zyydteKCQ@mail.gmail.com>
<CAGjGUAK6j4K3OMocdtPZRwTyF_U7Y47-bzxUDu4ZeUdg35Vtnw@mail.gmail.com>
<SY7PR01MB109210F944A86A8771BC5EE2AB640A@SY7PR01MB10921.ausprd01.prod.outlook.com>
<CAOzEurSa37w_wgP7SeVicsoo5ERXc4V7XQH2xee5YM-W9uRRBA@mail.gmail.com>
<SY7PR01MB10921CD524617DCF4FE8E2565B60C2@SY7PR01MB10921.ausprd01.prod.outlook.com>
<CAOzEurS5s9cbXP7XT0EHe9KynLqsjJt56mqL+ZAPKD0jvrYPBw@mail.gmail.com>
<CAOzEurRAiBfN-f5juywYzjS+5rWXTSSr3jaVaCJ39TJnwvUimQ@mail.gmail.com>
<[email protected]>
On Sat, May 23, 2026 at 10:35 PM Laurenz Albe <[email protected]> wrote:
> The patch looks fine to me too.
Thanks all for the reviews and LGTMs!
Before moving this forward, I noticed there is one thing in the patch
that I should fix first.
When hot_standby_feedback=on, the location where the standby's xmin is
recorded on the primary depends on whether physical replication slot
is used:
- Without a replication slot: the xmin is held on the walsender's PGPROC
- With a replication slot: the xmin is held on the replication slot itself
I summarized this behavior in my blog:
https://dev.to/shinyakato_/4-causes-of-table-bloat-in-postgresql-and-how-to-address-them-3ec9
The current patch reports the latter case as XHB_REPLICATION_SLOT with
the message "logical replication slot", which is misleading because it
is actually a physical slot used by a standby with
hot_standby_feedback=on. I will fix this and post an updated patch
later.
--
Best regards,
Shinya Kato
NTT OSS Center
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Report oldest xmin source when autovacuum cannot remove tuples
In-Reply-To: <CAOzEurQsmFkf5_+z8ymj6kTdUF8qJBr8NAs02Ha1yUvJ0Amx_g@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox