Re: md.c should not call files "relations"

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: md.c should not call files "relations"
Date: 2009-08-05 13:42:32
Message-ID: 4A798C48.5030705@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Werner Echezuria 2009-08-05 13:54:14 problem with splitting a string
Previous Message Magnus Hagander 2009-08-05 13:13:48 Re: Shipping documentation untarred