Re: Count and log pages set all-frozen by vacuum - Mailing list pgsql-hackers

From Melanie Plageman
Subject Re: Count and log pages set all-frozen by vacuum
Date
Msg-id CAAKRu_YNJZXQMC2FEWa-TMvNq6Mw51pH=dDWKB5wKRqeyLUE6g@mail.gmail.com
Whole thread Raw
In response to Re: Count and log pages set all-frozen by vacuum  (Alastair Turner <minion@decodable.me>)
List pgsql-hackers
On Thu, Oct 31, 2024 at 11:56 AM Alastair Turner <minion@decodable.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
curioususer something specific enough to look up. It also at least alerts the user to the fact that the number can't
justbe 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



pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: [PATCH] Improve code coverage of network address functions
Next
From: Masahiko Sawada
Date:
Subject: Re: Fix for consume_xids advancing XIDs incorrectly