Re: md.c should not call files "relations" - Mailing list pgsql-hackers

From Tom Lane
Subject Re: md.c should not call files "relations"
Date
Msg-id 10486.1249483725@sss.pgh.pa.us
Whole thread Raw
In response to Re: md.c should not call files "relations"  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: md.c should not call files "relations"  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
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.

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


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Adding error message "source"
Next
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Reserve the shared memory region during backend startup on