| From: | Shinya Kato <shinya11(dot)kato(at)gmail(dot)com> |
|---|---|
| To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
| Cc: | Japin Li <japinli(at)hotmail(dot)com>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Report oldest xmin source when autovacuum cannot remove tuples |
| Date: | 2026-05-28 05:34:54 |
| Message-ID: | CAOzEurQsmFkf5_+z8ymj6kTdUF8qJBr8NAs02Ha1yUvJ0Amx_g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, May 23, 2026 at 10:35 PM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-05-28 05:46:45 | Re: Set notice receiver before libpq connection startup |
| Previous Message | Fujii Masao | 2026-05-28 05:22:21 | Re: Set notice receiver before libpq connection startup |