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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Marko Kreen" <markokr(at)gmail(dot)com>
Cc: "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Heikki Linnakangas" <heikki(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgsql: Add relation fork support to pg_relation_size() function.
Date: 2008-10-03 12:37:07
Message-ID: 22313.1223037427@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

"Marko Kreen" <markokr(at)gmail(dot)com> writes:
> On 10/3/08, Gregory Stark <stark(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Eisentraut 2008-10-03 15:35:17 pgsql: Fix coverage targets so that HTML view is reliably updated when
Previous Message Marko Kreen 2008-10-03 11:27:50 Re: pgsql: Add relation fork support to pg_relation_size() function.

Browse pgsql-hackers by date

  From Date Subject
Next Message Brian Hurt 2008-10-03 13:36:19 Re: Block-level CRC checks
Previous Message Tom Lane 2008-10-03 12:28:15 Re: numeric_big test