On Tue, Mar 24, 2020 at 2:37 PM Masahiko Sawada
<masahiko.sawada@2ndquadrant.com> wrote:
>
> 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.
>
okay, thanks.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com