From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | michael(at)paquier(dot)xyz |
Cc: | hzhang(at)pivotal(dot)io, andres(at)anarazel(dot)de, thomas(dot)munro(at)gmail(dot)com, sdn(at)amazon(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Print physical file path when checksum check fails |
Date: | 2020-02-19 06:00:54 |
Message-ID: | 20200219.150054.515577387799304944.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Wed, 19 Feb 2020 13:28:04 +0900, Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2020-02-19 06:30:13 | Re: plan cache overhead on plpgsql expression |
Previous Message | Amit Kapila | 2020-02-19 05:42:18 | Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager |