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