Tom Lane wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> I note that many of the messages currently print the relpath() of the
>> relation, and don't include the affected segment suffix. For example:
>
>> could not read block 140000 of relation base/11566/24614: read only 1
>> of 8192 bytes
>
>> If we change them to point to the exactly right filename including
>> segment suffix, then the block number becomes confusing, since that
>> would still refer block number within the relation, not the segment.
>
> Hmm, good point. I don't think the byte-offset solution is usable,
> because of the INT64_FORMAT problem. What I would vote for is just
> continuing to show the block number relative to the whole relation,
> while (as much as possible) showing the actual filesystem pathname of
> the file being mentioned. This would mean that anyone trying to
> interpret the block number would have to be aware of what it meant
> and do the appropriate modulo calculation, but frankly I doubt that all
> that many people will care about exactly what offset is implied.
Ok. The most likely scenario where it would be confusing would be if you
get an error along the lines of "read error on block 200000 in file
XXX.1": you look at file XXX.1 and conclude that the file must be
truncated because the file is much shorter than 200000 blocks. Some
low-level knowledge is indeed needed to interpret that correctly, but
then again knowing to multiply by 8192 to get the offset is low-level
knowledge to begin with.
> BTW, I wonder whether it would be worth adding an entry point to fd.c
> to return the path name associated with a logical fd, rather than
> sprinkling extra relpath() calls throughout these messages.
Yes. I was going to add a function to md.c to construct the filename
from (SmgrRelation, ForkNumber, segment number), but that's an even
better idea.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com