Heikki Linnakangas <heikki.linnakan...@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.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
