| From: | Scott Ray <scott(at)scottray(dot)io> |
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | shinya11(dot)kato(at)gmail(dot)com, laurenz(dot)albe(at)cybertec(dot)at, japinli(at)hotmail(dot)com, qiuwenhuifx(at)gmail(dot)com, samimseih(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Report oldest xmin source when autovacuum cannot remove tuples |
| Date: | 2026-06-03 01:05:13 |
| Message-ID: | qOUvBIi7LC3GLKEjACMQAhPnYaE1m7Ta6XbMXN1gOVo3Mh6-Be6o_kQxQeCNXfo-Ywgc8k6myZrco4a41z-r7Dfqro4-nH73cB_tmSOczJk=@scottray.io |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> What I would want to investigate after seeing such a signal is not
> necessarily what happened to be blocking that particular VACUUM
> operation at some earlier point, but what is holding the xid horizon
> back now. For that purpose, a view exposing the current xid/xmin
> holders seems more useful and less misleading than adding a
> best-effort blocker guess to the VACUUM log.
I've been working on a view like this. It shows the horizon
contribution for each backend, prepared xact, replication slot, and
HSF walsender, broken down by class. It also shows - for each
contributor - how the horizon would shift if that holder were
removed.
Shinya said [1] that we could have a view in the future. We could
have both the logging and the view call a single function that reads
the procArray and other sources to gather the horizon information. I
think the logging and the view would complement each other.
Should I start another thread?
--
Scott Ray
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shinya Kato | 2026-06-03 01:11:01 | Re: Report oldest xmin source when autovacuum cannot remove tuples |
| Previous Message | Michael Paquier | 2026-06-03 01:01:57 | Re: Unify parallel worker handling for index builds and instrumentation |