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.kato@gmail.com> wrote:
On Wed, Jun 3, 2026 at 10:05 AM Scott Ray <scott@scottray.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