On Tue, Mar 24, 2020 at 2:37 PM Masahiko Sawada <masahiko.saw...@2ndquadrant.com> wrote: > > On Tue, 24 Mar 2020 at 13:53, Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Tue, Mar 24, 2020 at 9:46 AM Justin Pryzby <pry...@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