Tom Lane wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> Want me to change those or are you on it already?
>
> I'm going to bed --- if you wanna do it, have at it ...
Ok.
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.
Right now, the "relation xxx" is referring to the segmented virtual file
as whole, not to any specific segment. One option is to revert those
messages to 8.3 style:
could not read block 140000 of relation 1663/11566/24614: read only 1
of 8192 bytes
We'd need to include the fork there, so at least for forks other than
the main one it would become something like
could not read block 140000 of relation 1663/11566/24614/fsm: read
only 1 of 8192 bytes
Another option is to print the byte offset within segment file instead
of block number:
could not read 8129 bytes at offset 73138176 of file
"base/11566/24614.1": read only 1 bytes
That feels more concise and describes accurately what the failing OS
call was. However, it doesn't fit these two messages:
cannot extend relation %s beyond %u blocks could not truncate relation %s to %u blocks: it's only %u blocks now
since those genuinely don't refer to any particular segment. Also, if we
want to support RELSEG_SIZE > 4GB, we'd have to use INT64_FORMAT in the
format strings, and I don't think that works nicely with translations.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
