Re: Count and log pages set all-frozen by vacuum

On Thu, 31 Oct 2024 at 15:26, Melanie Plageman <melanieplageman(at)gmail(dot)com>
wrote:

> On Thu, Oct 31, 2024 at 11:15 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> >
> > On Thu, Oct 31, 2024 at 10:22 AM Melanie Plageman
> > <melanieplageman(at)gmail(dot)com> wrote:
> > > It seems a better solution would be to find a way to document it or
> > > phrase it clearly in the log. It is true that these pages were set
> > > all-frozen in the VM. It is just that some of them were later removed.
> > > And we don't know which ones those are. Is there a way to make this
> > > clear?
> >
> > Probably not, but I don't think that it's worth worrying about. ISTM
> > that it's inevitable that somebody might get confused whenever we
> > expose implementation details such as these. This particular example
> > doesn't seem particularly concerning to me.
> >
> > Fundamentally, the information that you're showing is a precisely
> > accurate account of the work performed by VACUUM. If somebody is
> > bothered by the fact that we're setting VM bits for pages that just
> > get truncated anyway, then they're bothered by the reality of what
> > VACUUM does -- and not by the instrumentation itself.
>
> Makes sense to me. Though, I'm looking at it as a developer.
>

For user consumption, to reduce the number of puzzled questions, I'd
suggest adding a line to the log output of the form

visibility map: %u pages set all frozen, up to %u may have been removed
from the table

rather than appending the info to the frozen: line of the output. By
spelling visibility map out in full it gives the curious user something
specific enough to look up. It also at least alerts the user to the fact
that the number can't just be subtracted from a total.