From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [PATCHES] Fix for large file support |
Date: | 2007-04-06 18:45:46 |
Message-ID: | 16229.1175885146@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
[ redirecting to -hackers for wider comment ]
Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> 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
--disable-largefile).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2007-04-06 18:56:21 | Re: Load distributed checkpoint V3 |
Previous Message | Zdenek Kotala | 2007-04-06 18:36:38 | Re: Fix for large file support |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2007-04-06 18:56:21 | Re: Load distributed checkpoint V3 |
Previous Message | Zdenek Kotala | 2007-04-06 18:36:38 | Re: Fix for large file support |