On Mon, 2002-08-12 at 09:39, Andrew Sullivan wrote:
> On Sat, Aug 10, 2002 at 09:21:07AM -0500, Greg Copeland wrote:
>
> > I'm actually amazed that postgres isn't already using large file
> > support. Especially for tools like dump.
>
> Except it would only cause confusion if you ran such a program on a
> system that didn't itself have largefile support. Better to make the
> admin turn all these things on on purpose, until everyone is running
> 64 bit systems everywhere.
If by "turn...on", you mean recompile, that's a horrible idea IMO.
Besides, you're expecting that an admin is going to know that he even
needs to recompile to obtain this feature let alone that he'd interested
in compiling his own installation. Whereas, more then likely he'll know
off hand (or can easily find out) if his FS/system supports large files
(>32 bit sizes).
Seems like, systems which can natively support this feature should have
it enabled by default. It's a different issue if an admin attempts to
create files larger than what his system and/or FS can support.
I guess what I'm trying to say here is, it's moving the problem from
being a postgres specific issue (not compiled in -- having to recompile
and install and not knowing if it's (dis)enabled) to a general body of
knowledge (does my system support such-n-such capabilities).
If a recompile time is still much preferred by the core developers,
perhaps a log entry can be created which at least denotes the current
status of such a feature when a compile time option is required. Simply
having an entry of, "LOG: LARGE FILE SUPPORT (DIS)ENABLED (64-bit file
sizes)", etc...things along those lines. Of course, having a
"--enable-large-files" would be nice too.
This would seemingly make sense in other contexts too. Imagine a
back-end compiled with large file support and someone else using fe
tools which does not support it. How are they going to know if their
fe/be supports this feature unless we let them know?
Greg
