Re: Report oldest xmin source when autovacuum cannot remove tuples - Mailing list pgsql-hackers

From Shinya Kato
Subject Re: Report oldest xmin source when autovacuum cannot remove tuples
Date
Msg-id CAOzEurQsmFkf5_+z8ymj6kTdUF8qJBr8NAs02Ha1yUvJ0Amx_g@mail.gmail.com
Whole thread
In response to autovacuum: automatically propagate updated parameters  (Zsolt Parragi <zsolt.parragi@percona.com>)
List 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



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Set notice receiver before libpq connection startup
Next
From: Chao Li
Date:
Subject: Re: Set notice receiver before libpq connection startup