Skip to content

Commit b175b9c

Browse files
VACUUM VERBOSE: Don't report "pages removed".
It doesn't make any sense to report this information, since VACUUM VERBOSE reports on heap relation truncation directly. This was an oversight in commit 7ab96cf, which made VACUUM VERBOSE output a little more consistent with nearby autovacuum-specific log output. Adjust comments that describe how this is supposed to work in passing. Also bring truncation-related VACUUM VERBOSE output in line with the convention established for VACUUM VERBOSE output by commit f4f4a64. Author: Peter Geoghegan <pg@bowt.ie> Backpatch: 14-, where VACUUM VERBOSE's output changed.
1 parent c4f7a6b commit b175b9c

File tree

1 file changed

+17
-19
lines changed

1 file changed

+17
-19
lines changed

src/backend/access/heap/vacuumlazy.c

Lines changed: 17 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -1627,34 +1627,31 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
16271627
update_index_statistics(vacrel);
16281628

16291629
/*
1630-
* If table has no indexes and at least one heap pages was vacuumed, make
1631-
* log report that lazy_vacuum_heap_rel would've made had there been
1632-
* indexes (having indexes implies using the two pass strategy).
1633-
*
1634-
* We deliberately don't do this in the case where there are indexes but
1635-
* index vacuuming was bypassed. We make a similar report at the point
1636-
* that index vacuuming is bypassed, but that's actually quite different
1637-
* in one important sense: it shows information about work we _haven't_
1638-
* done.
1639-
*
1640-
* log_autovacuum output does things differently; it consistently presents
1641-
* information about LP_DEAD items for the VACUUM as a whole. We always
1642-
* report on each round of index and heap vacuuming separately, though.
1630+
* When the table has no indexes (i.e. in the one-pass strategy case),
1631+
* make log report that lazy_vacuum_heap_rel would've made had there been
1632+
* indexes. (As in the two-pass strategy case, only make this report when
1633+
* there were LP_DEAD line pointers vacuumed in lazy_vacuum_heap_page.)
16431634
*/
16441635
if (vacrel->nindexes == 0 && vacrel->lpdead_item_pages > 0)
16451636
ereport(elevel,
16461637
(errmsg("table \"%s\": removed %lld dead item identifiers in %u pages",
16471638
vacrel->relname, (long long) vacrel->lpdead_items,
16481639
vacrel->lpdead_item_pages)));
16491640

1641+
/*
1642+
* Make a log report summarizing pruning and freezing.
1643+
*
1644+
* The autovacuum specific logging in heap_vacuum_rel summarizes an entire
1645+
* VACUUM operation, whereas each VACUUM VERBOSE log report generally
1646+
* summarizes a single round of index/heap vacuuming (or rel truncation).
1647+
* It wouldn't make sense to report on pruning or freezing while following
1648+
* that convention, though. You can think of this log report as a summary
1649+
* of our first pass over the heap.
1650+
*/
16501651
initStringInfo(&buf);
16511652
appendStringInfo(&buf,
16521653
_("%lld dead row versions cannot be removed yet, oldest xmin: %u\n"),
16531654
(long long) vacrel->new_dead_tuples, vacrel->OldestXmin);
1654-
appendStringInfo(&buf, ngettext("%u page removed.\n",
1655-
"%u pages removed.\n",
1656-
vacrel->pages_removed),
1657-
vacrel->pages_removed);
16581655
appendStringInfo(&buf, ngettext("Skipped %u page due to buffer pins, ",
16591656
"Skipped %u pages due to buffer pins, ",
16601657
vacrel->pinskipped_pages),
@@ -2377,6 +2374,7 @@ lazy_vacuum_heap_rel(LVRelState *vacrel)
23772374
* We set all LP_DEAD items from the first heap pass to LP_UNUSED during
23782375
* the second heap pass. No more, no less.
23792376
*/
2377+
Assert(tupindex > 0);
23802378
Assert(vacrel->num_index_scans > 1 ||
23812379
(tupindex == vacrel->lpdead_items &&
23822380
vacuumed_pages == vacrel->lpdead_item_pages));
@@ -3295,7 +3293,7 @@ lazy_truncate_heap(LVRelState *vacrel)
32953293
vacrel->rel_pages = new_rel_pages;
32963294

32973295
ereport(elevel,
3298-
(errmsg("\"%s\": truncated %u to %u pages",
3296+
(errmsg("table \"%s\": truncated %u to %u pages",
32993297
vacrel->relname,
33003298
orig_rel_pages, new_rel_pages),
33013299
errdetail_internal("%s",
@@ -3359,7 +3357,7 @@ count_nondeletable_pages(LVRelState *vacrel, bool *lock_waiter_detected)
33593357
if (LockHasWaitersRelation(vacrel->rel, AccessExclusiveLock))
33603358
{
33613359
ereport(elevel,
3362-
(errmsg("\"%s\": suspending truncate due to conflicting lock request",
3360+
(errmsg("table \"%s\": suspending truncate due to conflicting lock request",
33633361
vacrel->relname)));
33643362

33653363
*lock_waiter_detected = true;

0 commit comments

Comments
 (0)