| From: | Sami Imseih <samimseih(at)gmail(dot)com> |
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | shinya11(dot)kato(at)gmail(dot)com, scott(at)scottray(dot)io, laurenz(dot)albe(at)cybertec(dot)at, japinli(at)hotmail(dot)com, qiuwenhuifx(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-02 23:34:32 |
| Message-ID: | CAA5RZ0tF3B-NASWX8kFQ6jbXyRzkpkQh=CuWs6Zmd+Fw3Wu+Fg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
> This may be just my personal preference, but I'd rather see
> information about xid horizon retention exposed through a SQL-visible
> interface than added to the VACUUM log.
>
> VACUUM VERBOSE already reports the removable cutoff and how old it was
> when the operation ended. That seems sufficient as a signal that the
> xid horizon is being held back.
>
> 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.
+1, I also had a similar comment at the bottom of [1], where this information
is better to be exposed in SQL for proactive monitoring.
--
Sami Imseih
Amazon Web Services (AWS)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Henson Choi | 2026-06-02 23:50:28 | Re: Row pattern recognition |
| Previous Message | Jeff Davis | 2026-06-02 23:33:41 | Commit Sequence Numbers and Visibility |