On Mon, Mar 23, 2020 at 1:46 PM Justin Pryzby <pry...@telsasoft.com> wrote:
>
> 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.
>
What extra information we can print that can help? The main problem I
see is that we need to sprinkle errorcallback update function at many
more places. We can think of writing a wrapper function for FSM calls
used in a vacuum, but I think those can be used only for vacuum.
> 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;
>
In what kind of errors will this help?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
