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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: md.c should not call files "relations"
Дата
Msg-id 10486.1249483725@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: md.c should not call files "relations"  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: md.c should not call files "relations"  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Adding error message "source"
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Reserve the shared memory region during backend startup on