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

2008-10-06 Thread Heikki Linnakangas
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

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

2008-10-06 Thread Magnus Hagander
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

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

2008-10-06 Thread Gregory Stark
Magnus Hagander [EMAIL PROTECTED] 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

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

2008-10-06 Thread Tom Lane
Greg Stark [EMAIL PROTECTED] 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.

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

2008-10-06 Thread Heikki Linnakangas
Gregory Stark wrote: Magnus Hagander [EMAIL PROTECTED] 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

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

2008-10-06 Thread Greg Stark
On Mon, Oct 6, 2008 at 11:32 AM, Heikki Linnakangas [EMAIL PROTECTED] 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

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

2008-10-03 Thread Gregory Stark
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

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

2008-10-03 Thread Marko Kreen
On 10/3/08, Gregory Stark [EMAIL PROTECTED] 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

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

2008-10-03 Thread Tom Lane
Marko Kreen [EMAIL PROTECTED] writes: On 10/3/08, Gregory Stark [EMAIL PROTECTED] 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