Re: error context for vacuum to include block number

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: error context for vacuum to include block number
Date: 2019-12-15 13:07:08
Message-ID: 20191215130708.GA19063@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 13, 2019 at 04:47:35PM -0600, Justin Pryzby wrote:
> It's related code which I cleaned up before adding new stuff. Not essential,
> thus separate (0002 should be backpatched).

The issue just causes some extra work and that's not a bug, so applied
without a backpatch.

>> The refactoring in 0003 is interesting, so I would be tempted to merge
>> it. Now you have one small issue in it:
>> - /*
>> - * Forget the now-vacuumed tuples, and press on, but be careful
>> - * not to reset latestRemovedXid since we want that value to be
>> - * valid.
>> - */
>> + lazy_vacuum_heap_index(onerel, vacrelstats, Irel, nindexes, indstats);
>> vacrelstats->num_dead_tuples = 0;
>> - vacrelstats->num_index_scans++;
>> You are moving this comment within lazy_vacuum_heap_index, but it
>> applies to num_dead_tuples and not num_index_scans, no? You should
>> keep the incrementation of num_index_scans within the routine though.
>
> Thank you, fixed.

For 0003, I think that lazy_vacuum_heap_index() can be confusing as
those indexes are unrelated to heap. Why not naming it just
lazy_vacuum_all_indexes()? The routine should also have a header
describing it.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-12-15 16:06:39 Re: more backtraces
Previous Message Andrey Lepikhov 2019-12-15 10:56:44 Re: Optimization of NestLoop join in the case of guaranteed empty inner subtree