Re: error context for vacuum to include block number
От | Amit Kapila |
---|---|
Тема | Re: error context for vacuum to include block number |
Дата | |
Msg-id | CAA4eK1KaWto3+4+EsLPRFL6HKs8=_42V2ivAFEPBU-o_o6AYXw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: error context for vacuum to include block number (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: error context for vacuum to include block number
|
Список | pgsql-hackers |
On Mon, Mar 23, 2020 at 1:46 PM Justin Pryzby <pryzby@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
В списке pgsql-hackers по дате отправления: