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
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 |