Re: error context for vacuum to include block number - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: error context for vacuum to include block number
Date
Msg-id CA+fd4k5TFS87WXsgne17dbYGUq79bvx-WnumfF22eqkjCHtXkA@mail.gmail.com
Whole thread Raw
In response to Re: error context for vacuum to include block number  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: error context for vacuum to include block number  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Tue, 24 Mar 2020 at 13:53, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Tue, Mar 24, 2020 at 9:46 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
> >
> > On Mon, Mar 23, 2020 at 02:25:14PM +0530, Amit Kapila wrote:
> > > > 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?
> >
> > If there's an I/O error on an _fsm file, for one.
> >
>
> If there is a read or write failure, then we give error like below
> which already has required information.
> ereport(ERROR,
> (errcode_for_file_access(),
> errmsg("could not read block %u in file \"%s\": %m",
> blocknum, FilePathName(v->mdfd_vfd))));

Yeah, you're right. We, however, cannot see that the error happened
while recording freespace or while vacuuming freespace map but perhaps
we can see the situation by seeing the error message in most cases. So
I'm okay with the current set of phases.

I'll also test the current version of patch today.

Regards,

-- 
Masahiko Sawada            http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Some problems of recovery conflict wait events
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Corruption during WAL replay