Re: Print physical file path when checksum check fails

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: Print physical file path when checksum check fails
Дата
Msg-id 20200219.150054.515577387799304944.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на Re: Print physical file path when checksum check fails  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Print physical file path when checksum check fails  (Michael Paquier <michael@paquier.xyz>)
Re: Print physical file path when checksum check fails  (Hubert Zhang <hzhang@pivotal.io>)
Список pgsql-hackers
At Wed, 19 Feb 2020 13:28:04 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> On Wed, Feb 19, 2020 at 01:07:36PM +0900, Kyotaro Horiguchi wrote:
> > If we also verify checksum in md layer, callback is overkill since the
> > immediate caller consumes the event immediately.  We can signal the
> > error by somehow returning a file tag.
> 
> FWIW, I am wondering if there is any need for a change here and
> complicate more the code.  If you know the block number, the page size
> and the segment file size you can immediately guess where is the
> damaged block.  The first information is already part of the error

I have had support requests related to broken block several times, and
(I think) most of *them* had hard time to locate the broken block or
even broken file.  I don't think it is useles at all, but I'm not sure
it is worth the additional complexity.

> damaged block.  The first information is already part of the error
> message, and the two other ones are constants defined at
> compile-time.

May you have misread the snippet?

What Hubert proposed is:

 "invalid page in block %u of relation file %s; zeroing out page",
    blkno, <filename>

The second format in my messages just before is:
  "invalid page in block %u in relation %u, file \"%s\"",
     blockNum, smgr->smgr_rnode.node.relNode, smgrfname()

All of them are not compile-time constant at all.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: plan cache overhead on plpgsql expression