public inbox for [email protected]
help / color / mirror / Atom feedFrom: Shinya Kato <[email protected]>
To: Sami Imseih <[email protected]>
Cc: Kyotaro Horiguchi <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Subject: Re: Report oldest xmin source when autovacuum cannot remove tuples
Date: Wed, 3 Jun 2026 10:11:01 +0900
Message-ID: <CAOzEurTXNzS8C1_pE3ijwhDt-YZgs_H+JCR3dBg9GzKJszdg1Q@mail.gmail.com> (raw)
In-Reply-To: <CAA5RZ0tF3B-NASWX8kFQ6jbXyRzkpkQh=CuWs6Zmd+Fw3Wu+Fg@mail.gmail.com>
References: <[email protected]>
<3bnBUxwx2npXqvHL0trI11LOOvzQ7LI0GzWqbaj5SJnk7DTb1uzStGveKwj0JJmBW4ebzGIF3az7of4I4rQeaO_PRqDnnClCduPyjM6gPgM=@scottray.io>
<CAOzEurTC+5xuH_X2EBWjW0Fs9iuTq3OMA=1FfT4xx1wYbCAR6g@mail.gmail.com>
<[email protected]>
<CAA5RZ0tF3B-NASWX8kFQ6jbXyRzkpkQh=CuWs6Zmd+Fw3Wu+Fg@mail.gmail.com>
On Wed, Jun 3, 2026 at 8:34 AM Sami Imseih <[email protected]> wrote:
>
> 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.
I agree that exposing xid horizon retention information via a
SQL-visible interface is valuable. However, I believe reporting it
in the VACUUM log is also important: a view only shows the current
state, so once a blocker has gone away there is no way to determine,
after the fact, what was holding the horizon back at the time a
particular VACUUM ran. Logs are the only durable record we have for
that kind of post-hoc analysis.
That said, I share the concern about emitting best-effort
information in the VACUUM log, which otherwise reports facts
observed during the operation. Would it be acceptable if we
reported the exact blocker -- captured at the moment OldestXmin is
computed -- rather than a best-effort guess reconstructed
afterwards?
--
Best regards,
Shinya Kato
NTT OSS Center
view thread (34+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Report oldest xmin source when autovacuum cannot remove tuples
In-Reply-To: <CAOzEurTXNzS8C1_pE3ijwhDt-YZgs_H+JCR3dBg9GzKJszdg1Q@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox