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
Re: Print physical file path when checksum check fails |
Список | 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 по дате отправления: