On Mon, Aug 12, 2002 at 11:44:24AM -0400, Lamar Owen wrote:
> > The problem is not just a system-level one, but a filesystem-level
> > one. Enabling 64 bits by default might be dangerous, because a DBA
> > might think "oh, it supports largefiles by default" and therefore not
> > notice that the filesystem itself is not mounted with largefile
> > support.
> keep discussing the issues involved, and I'll see what comes of it. I don't
> have an direct experience with the largefile support, and am learning as I go
> with this.
I do have experience with both of these cases. We're hosted in a
managed-hosting environment, and one day one of the sysadmins there
must've remounted a filesystem without largefile support. Poof! I
started getting all sorts of strange pg_dump problems. It wasn't
hard to track down, except that I was initially surprised by the
errors, since I'd just _enabled_ large file support.
This is an area that is not encountered terribly often, actually,
because postgres itself breaks its files at 1G. Most people's dump
files either don't reach the 2G limit, or they use split (a
reasonable plan).
There are, in any case, _lots_ of problems with these large files.
You not only need to make sure that pg_dump and friends can support
files bigger than 2G. You need to make sure that you can move the
files around (your file transfer commands), that you can compress the
files (how is gzip compiled? bzip2?), and even that you r backup
software takes the large file. In a few years, when all
installations are ready for this, it seems like it'd be a good idea
to turn this on by default. Right now, I think the risks are at
least as great as those incurred by telling people they need to
recompile.
A
--
----
Andrew Sullivan 87 Mowat Avenue
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M6K 3E3
+1 416 646 3304 x110
