Re: Report oldest xmin source when autovacuum cannot remove tuples

HI Shinya
> 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.
Agree +1,There's no denying that checking SQL is easier than checking logs.
Logs are also important though. In fact, I think we should apply this patch
first and implement the SQL later.

Thanks

On Wed, Jun 3, 2026 at 9:25 AM Shinya Kato <shinya11(dot)kato(at)gmail(dot)com> wrote:

> On Wed, Jun 3, 2026 at 10:05 AM Scott Ray <scott(at)scottray(dot)io> wrote:
> > 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?
>
> My mild preference would be to keep the discussion on this thread,
> since the shared function design is central to both the log and the
> view and may be easier to keep aligned in one place. That said, I'm
> not strongly attached to that, so please pick whichever feels more
> convenient.
>
>
> --
> Best regards,
> Shinya Kato
> NTT OSS Center
>