Skip to content

Commit 0d892cf

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 4d1816e commit 0d892cf

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
@@ -1630,34 +1630,31 @@ lazy_scan_heap(LVRelState *vacrel, VacuumParams *params, bool aggressive)
16301630
update_index_statistics(vacrel);
16311631

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

1644+
/*
1645+
* Make a log report summarizing pruning and freezing.
1646+
*
1647+
* The autovacuum specific logging in heap_vacuum_rel summarizes an entire
1648+
* VACUUM operation, whereas each VACUUM VERBOSE log report generally
1649+
* summarizes a single round of index/heap vacuuming (or rel truncation).
1650+
* It wouldn't make sense to report on pruning or freezing while following
1651+
* that convention, though. You can think of this log report as a summary
1652+
* of our first pass over the heap.
1653+
*/
16531654
initStringInfo(&buf);
16541655
appendStringInfo(&buf,
16551656
_("%lld dead row versions cannot be removed yet, oldest xmin: %u\n"),
16561657
(long long) vacrel->new_dead_tuples, vacrel->OldestXmin);
1657-
appendStringInfo(&buf, ngettext("%u page removed.\n",
1658-
"%u pages removed.\n",
1659-
vacrel->pages_removed),
1660-
vacrel->pages_removed);
16611658
appendStringInfo(&buf, ngettext("Skipped %u page due to buffer pins, ",
16621659
"Skipped %u pages due to buffer pins, ",
16631660
vacrel->pinskipped_pages),
@@ -2379,6 +2376,7 @@ lazy_vacuum_heap_rel(LVRelState *vacrel)
23792376
* We set all LP_DEAD items from the first heap pass to LP_UNUSED during
23802377
* the second heap pass. No more, no less.
23812378
*/
2379+
Assert(tupindex > 0);
23822380
Assert(vacrel->num_index_scans > 1 ||
23832381
(tupindex == vacrel->lpdead_items &&
23842382
vacuumed_pages == vacrel->lpdead_item_pages));
@@ -3293,7 +3291,7 @@ lazy_truncate_heap(LVRelState *vacrel)
32933291
vacrel->rel_pages = new_rel_pages;
32943292

32953293
ereport(elevel,
3296-
(errmsg("\"%s\": truncated %u to %u pages",
3294+
(errmsg("table \"%s\": truncated %u to %u pages",
32973295
vacrel->relname,
32983296
old_rel_pages, new_rel_pages),
32993297
errdetail_internal("%s",
@@ -3357,7 +3355,7 @@ count_nondeletable_pages(LVRelState *vacrel, bool *lock_waiter_detected)
33573355
if (LockHasWaitersRelation(vacrel->rel, AccessExclusiveLock))
33583356
{
33593357
ereport(elevel,
3360-
(errmsg("\"%s\": suspending truncate due to conflicting lock request",
3358+
(errmsg("table \"%s\": suspending truncate due to conflicting lock request",
33613359
vacrel->relname)));
33623360

33633361
*lock_waiter_detected = true;

0 commit comments

Comments
 (0)