MIME-Version: 1.0
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>
 <6634e1b0b5b74e5c2e3b06201120a81e11d82a55.camel@cybertec.at>
In-Reply-To: <6634e1b0b5b74e5c2e3b06201120a81e11d82a55.camel@cybertec.at>
From: Shinya Kato <shinya11.kato@gmail.com>
Date: Thu, 28 May 2026 14:34:54 +0900
Message-ID: 
 <CAOzEurQsmFkf5_+z8ymj6kTdUF8qJBr8NAs02Ha1yUvJ0Amx_g@mail.gmail.com>
Subject: Re: Report oldest xmin source when autovacuum cannot remove tuples
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Japin Li <japinli@hotmail.com>, wenhui qiu <qiuwenhuifx@gmail.com>,
	Sami Imseih <samimseih@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAOzEurQsmFkf5_%2Bz8ymj6kTdUF8qJBr8NAs02Ha1yUvJ0Amx_g%40mail.gmail.com>
Precedence: bulk

On Sat, May 23, 2026 at 10:35=E2=80=AFPM Laurenz Albe <laurenz.albe@cyberte=
c.at> 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=3Don, 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=3Don. I will fix this and post an updated patch
later.


--
Best regards,
Shinya Kato
NTT OSS Center