Re: error context for vacuum to include block number

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: error context for vacuum to include block number
Date: 2020-03-23 08:16:39
Message-ID: 20200323081639.GI2563@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 23, 2020 at 04:39:54PM +0900, Masahiko Sawada wrote:
> I've already commented on earlier patch but I personally think we'd be
> better to report freespace map vacuum as a separate phase. The
> progress report of vacuum command is used to know the progress but
> this error context would be useful for diagnostic of failure such as
> disk corruption. For visibility map, I think the visibility map bit
> that are processed during vacuum is exactly corresponding to the block
> number but since freespace map vacuum processes the range of blocks
> I've sometimes had trouble with identifying the cause of the problem.

Yea, and it would be misleading if we reported "while scanning block..of
relation" if we actually failed while writing its FSM.

My previous patches did this:

+ case VACUUM_ERRCB_PHASE_VACUUM_FSM:
+ errcontext("while vacuuming free space map of relation \"%s.%s\"",
+ cbarg->relnamespace, cbarg->relname);
+ break;

Are you suggesting it should report the start (or end?) block number ?

--
Justin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-03-23 08:17:13 Re: shared-memory based stats collector
Previous Message Masahiko Sawada 2020-03-23 07:39:54 Re: error context for vacuum to include block number