On Wed, Feb 19, 2020 at 03:00:54PM +0900, Kyotaro Horiguchi wrote: > 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.
I handle stuff like that from time to time, and any reports usually go down to people knowledgeable about PostgreSQL enough to know the difference. My point is that in order to know where a broken block is physically located on disk, you need to know four things: - The block number. - The physical location of the relation. - The size of the block. - The length of a file segment. The first two items are printed in the error message, and you can guess easily the actual location (file, offset) with the two others. I am not necessarily against improving the error message here, but FWIW I think that we need to consider seriously if the code complications and the maintenance cost involved are really worth saving from one simple calculation. Particularly, quickly reading through the patch, I am rather unhappy about the shape of the second patch which pushes down the segment number knowledge into relpath.c, and creates more complication around the handling of zero_damaged_pages and zero'ed pages. -- Michael
signature.asc
Description: PGP signature
