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. [1] https://www.postgresql.org/message-id/CAA5RZ0sjMgMo4Xg-niyyF-CpkQ_CK6uOfNKYT%3D9RmiBkAxQkbQ%40mail.gmail.com -- Sami Imseih Amazon Web Services (AWS)
