Re: [HACKERS] Linux Largefile Support In Postgresql RPMS

On Mon, 2002-08-12 at 10:30, Andrew Sullivan wrote:
> On Mon, Aug 12, 2002 at 10:15:46AM -0500, Greg Copeland wrote:
>
> > If by "turn...on", you mean recompile, that's a horrible idea IMO.
>
> Ah.  Well, that is what I meant.  Why is it horrible?  PostgreSQL
> doesn't take very long to compile.


Many reasons.  A DBA is not always the same thing as a developer (which
means it's doubtful he's even going to know about needed options to pass
-- if any).  Using a self compiled installation may not install the same
sense of reliability (I know that sounds odd) as using a distribution's
package.  DBA may not be a SA, which means he should probably not be
compiling and installing software on a system.  Furthermore, he may not
even have access to do so.

Means upgrading in the future may be problematic.  Someone compiled with
large file support.  He leaves.  New release comes out.  Someone else
upgrades and now finds things are broken.  Why?  If it supported it out
of the box, issue is avoided.

Lastly, and perhaps the most obvious, SA and DBA bodies of knowledge are
fairly distinct.  You should not expect a DBA to function as a SA.
Furthermore, SA and developer bodies of knowledge are also fairly
distinct.  You shouldn't expect a SA to know what compiler options he
needs to use to compile software on his system.  Especially for
something as obscure as large file 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).
>
> 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.  But I suspect that the developers would welcome autoconfig
> patches if someone offered them.


The distinction you make there is minor.  A SA, should know and
understand the capabilities of the systems he maintains (this is true
even if the SA and DBA are one).  This includes filesystem
capabilities.  A DBA, should only care about the system requirements and
trust that the SA can deliver those capabilities.  If a SA says, my
filesystems can support very large files, installs postgres, the DBA
should expect that match support in the database is already available.
Woe is his surprise when he finds out that his postgres installation
can't handle it?!

As for the concern for danger.  Hmm...my understanding is that the
result is pretty much the same thing as exceeding max file size.  That
is, if you attempt to read/write beyond what the filesystem can provide,
you're still going to get an error.  Is this really more dangerous than
simply reading/writing to a file which exceeds max system capabilities?
Either way, this issue exists and having large file support, seemingly,
does not effect it one way or another.

I guess I'm tying to say, the risk of seeing filesystem corruption or
even database corruption should not be effected by the use of large file
support.  Please correct me if I'm wrong.


Greg