If we expose LET_OS_MANAGE_FILESIZE, should we add a flag to the control file so that you can't start a backend that has that defined against a cluster that was initialized without it?

On Apr 6, 2007, at 2:45 PM, Tom Lane wrote:

[ redirecting to -hackers for wider comment ]

Zdenek Kotala <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
LET_OS_MANAGE_FILESIZE is good way. I think one problem of this option I
fixed. It is size of offset. I went thru the code and did not see any
other problem there. However, how you mentioned it need more testing. I
going to take server with large disk array and I will test it.

I would like to add --enable-largefile switch to configure file to
enable access to wide group of users. What you think about it?

Yeah, I was going to suggest the same thing --- but not with that switch name. We already use enable/disable-largefile to control whether 64-bit file access is built at all (this mostly affects pg_dump at the moment).

I think the clearest way might be to flip the sense of the variable.
I never found "LET_OS_MANAGE_FILESIZE" to be a good name anyway.  I'd
suggest "USE_SEGMENTED_FILES", which defaults to "on", and you can
turn it off via --disable-segmented-files if configure confirms your
OS has largefile support (thus you could not specify both this and

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Jim Nasby                                            [EMAIL PROTECTED]
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to