Re: pgsql: Add relation fork support to pg_relation_size() function.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pgsql: Add relation fork support to pg_relation_size() function.
Дата
Msg-id 22313.1223037427@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pgsql: Add relation fork support to pg_relation_size() function.  ("Marko Kreen" <markokr@gmail.com>)
Ответы Re: pgsql: Add relation fork support to pg_relation_size() function.  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
"Marko Kreen" <markokr@gmail.com> writes:
> On 10/3/08, Gregory Stark <stark@enterprisedb.com> wrote:
>> The other reason I thought of this is that if EDB or anyone else uses forks
>> for a private purpose then it would avoid the whole issue of conflicts. The
>> best option right now would be to set aside a range of values for private
>> purposes.

> Good idea.

No, it isn't, because the patch assumes that the set of possible fork
numbers is pretty compact (grep for uses of MAX_FORKNUM).

I don't believe for a moment that EDB, or anyone else competent enough
to put in a private fork definition, can't manage to add it to enum
ForkNumber.  They'd probably be well advised to operate with a private
setting of catversion anyway, which would ensure that installations
using this private fork wouldn't interoperate with backends not knowing
about it.  Once you've done that there's no need to worry about
conflicts.

I have no particular objection to the .fsm idea though --- that could be
implemented fairly simply with a lookup table while forming the file name.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: numeric_big test
Следующее
От: Brian Hurt
Дата:
Сообщение: Re: Block-level CRC checks