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 <[email protected]> wrote: > On Wed, Jun 3, 2026 at 10:05 AM Scott Ray <[email protected]> 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 >
