Horton

Re: Report oldest xmin source when autovacuum cannot remove tuples

Shinya Kato <shinya11.kato@gmail.com>

View thread
From: Shinya Kato <shinya11.kato@gmail.com>
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>
Date: 2026-05-28T05:34:54Z
Lists: pgsql-hackers 
On Sat, May 23, 2026 at 10:35 PM Laurenz Albe <laurenz.albe@cybertec.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=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