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

Log Message:
-----------
Add relation fork support to pg_relation_size() function. You can now pass
name of a fork ('main' or 'fsm', at the moment) to pg_relation_size() to
get the size of a specific fork. Defaults to 'main', if none given.

While we're at it, modify pg_relation_size to take a regclass as argument,
instead of separate variants taking oid and name. This change is
transparent to typical use where the table name is passed as a string
literal, like pg_relation_size('table'), but will break queries like
pg_relation_size(namecol), where namecol is of type name. text-type input
still works, and using a non-schema-qualified table name is not very
reliable anyway, so this is unlikely to break anyone's queries in practice.

Modified Files:
--------------
pgsql/doc/src/sgml:
func.sgml (r1.447 -> r1.448)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/func.sgml?r1=1.447&r2=1.448)
pgsql/src/backend/utils/adt:
dbsize.c (r1.20 -> r1.21)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/dbsize.c?r1=1.20&r2=1.21)
pgsql/src/include/catalog:
catversion.h (r1.490 -> r1.491)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/catversion.h?r1=1.490&r2=1.491)
pg_proc.h (r1.515 -> r1.516)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_proc.h?r1=1.515&r2=1.516)
pgsql/src/include/storage:
relfilenode.h (r1.17 -> r1.18)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/relfilenode.h?r1=1.17&r2=1.18)
pgsql/src/include/utils:
builtins.h (r1.320 -> r1.321)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/builtins.h?r1=1.320&r2=1.321)

Hm, I wonder if we should have made the forks use a fork "name" instead of a
number. It sure would be nicer to have files name 12345.fsm instead of another
opaque number.

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.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!

On 10/3/08, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> Hm, I wonder if we should have made the forks use a fork "name" instead of a
> number. It sure would be nicer to have files name 12345.fsm instead of another
> opaque number.
>
> 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.

--
marko

"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

Tom Lane wrote:
> 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.

Agreed.

> 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.

Yeah, I think it's a good idea nevertheless. While users don't need to
poke around in the data directory, for those people who do, it's more
pleasant if the files have self-explanatory names.

If we go with the ".fsm" extension, we'll get "12345.fsm.1" when the FSM
grows large enough to be segmented. Does anyone have a problem with a
filename with two dots? Shouldn't be a problem, I guess.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Heikki Linnakangas wrote:
> Tom Lane wrote:
>> 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.
>
> Agreed.
>
>> 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.
>
> Yeah, I think it's a good idea nevertheless. While users don't need to
> poke around in the data directory, for those people who do, it's more
> pleasant if the files have self-explanatory names.
>
> If we go with the ".fsm" extension, we'll get "12345.fsm.1" when the FSM
> grows large enough to be segmented. Does anyone have a problem with a
> filename with two dots? Shouldn't be a problem, I guess.

Windows used to have a problem with this, but none of the versions we're
even remotely close to supporting has an issue with it. And if Windows
now manages to deal with it, I doubt others have problems with it :-)

There may be (at least on Windows) GUI tools that don't deal with it
properly, but if you point one of those at your data directory you
deserve what you get :-P (All the ones builtin to the system work)

//Magnus

Magnus Hagander <magnus(at)hagander(dot)net> writes:

> Heikki Linnakangas wrote:
>
>> If we go with the ".fsm" extension, we'll get "12345.fsm.1" when the FSM
>> grows large enough to be segmented. Does anyone have a problem with a
>> filename with two dots? Shouldn't be a problem, I guess.

We could also just do 12345_fsm.1 like we do now but with the symbolic name.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!

Gregory Stark wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> Heikki Linnakangas wrote:
>>> If we go with the ".fsm" extension, we'll get "12345.fsm.1" when the FSM
>>> grows large enough to be segmented. Does anyone have a problem with a
>>> filename with two dots? Shouldn't be a problem, I guess.
>
> We could also just do 12345_fsm.1 like we do now but with the symbolic name.

or 12345fsm.1. I think 12345.fsm.1 looks the best.

FWIW, with the defaults of 8k block size and 1GB segments, the table
needs to be over 4TB in size until the FSM file needs to be segmented.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Mon, Oct 6, 2008 at 11:32 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>
> FWIW, with the defaults of 8k block size and 1GB segments, the table needs
> to be over 4TB in size until the FSM file needs to be segmented.

Hm, so on the one hand people will just have 12345.1, 12345.2, ... and
12345.fsm which is kind of neat.

On the other hand if they do have a problem with multiple periods they
won't find out until they have a pretty big database already and are
kind of stuck. And our regression tests won't test it at all.

--
greg

"Greg Stark" <stark(at)enterprisedb(dot)com> writes:
> On the other hand if they do have a problem with multiple periods they
> won't find out until they have a pretty big database already and are
> kind of stuck. And our regression tests won't test it at all.

Yeah. +1 for the _fsm approach, just in case.

regards, tom lane