On Wed, 03 Jun 2026 at 10:32, wenhui qiu <[email protected]> wrote: > 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. >
+1 for this idea. I don't think they conflict with each other — they just provide the same content from different perspectives. > 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 -- Regards, Japin Li ChengDu WenWu Information Technology Co., Ltd.
