Обсуждение: Re: pgsql: Add relation fork support to pg_relation_size() function.
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@enterprisedb.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@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
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@hagander.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@hagander.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.linnakangas@enterprisedb.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@enterprisedb.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