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

From: Melanie Plageman <melanieplageman(at)gmail(dot)com>
To: Alastair Turner <minion(at)decodable(dot)me>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Count and log pages set all-frozen by vacuum
Date: 2024-10-31 18:50:58
Message-ID: CAAKRu_YNJZXQMC2FEWa-TMvNq6Mw51pH=dDWKB5wKRqeyLUE6g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 31, 2024 at 11:56 AM Alastair Turner <minion(at)decodable(dot)me> wrote:
>
> 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.

Would it also be useful to have the number set all-visible? It seems
like if we added a new line prefixed with visibility map, it ought to
include all-visible and all-frozen then.
Something like this:
visibility map: %u pages set all-visible, %u pages set all-frozen.

I find it more confusing to say "up to X may have been removed from
the table." It's unclear what that means -- especially since we
already have "pages removed" in another part of the log message.

We actually could call visibilitymap_count() at the beginning of the
vacuum and then log the difference between that and the results of
calling it after finishing the vacuum. We currently call it after
truncating the table anyway. That won't tell you how many pages were
set all-frozen by this vacuum, as pages could have been unfrozen by
DML that occurred after the page was vacuumed. It might be useful in
addition to the line about the visibility map.

This is somewhat in conflict with Robert and Peter's points about how
autovacuum logging should be about what this vacuum did. But, we do
have lines that talk about the before and after values:

new relfrozenxid: 748, which is 3 XIDs ahead of previous value

So, we could do something like:
visibility map before: %u pages all-visible, %u pages all-frozen
visibility map after: %u pages all-visible, %u pages all-frozen
or
visibility map after: %u pages all-visible (%u more than before), %u
pages all-frozen (%u more than before)

I still prefer adding how many pages were set all-frozen by this vacuum, though.

- Melanie

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2024-10-31 18:53:34 Re: Fix for consume_xids advancing XIDs incorrectly
Previous Message Andrey M. Borodin 2024-10-31 18:45:49 Re: UUID v7