Re: [GENERAL] Linux Largefile Support In Postgresql RPMS

On Mon, 2002-08-12 at 11:40, Andrew Sullivan wrote:
> On Mon, Aug 12, 2002 at 11:07:51AM -0500, Greg Copeland wrote:
>
> > 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).
>
> This (and the "upgrade" argument) are simply documentation issues.
> If you check the FAQ_Solaris, there's already a line in there which
> tells you how to do it.

And?  What's you're point.  That somehow make it disappear?  Even if it
had been documented, it doesn't mean the documentation made it to the
right hands or was obviously located.  Just look at postgres'
documentation in general.  How often are people told to "read the
code".  Give me a break.  You're argument is a very weak straw.

>
> > 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.
>
> It seems to me that a DBA who is running a system which produces 2
> Gig dump files, and who can't compile Postgres, is in for a rocky
> ride.  Such a person needs at least a support contract, and in such a
> case the supporting organisation would be able to provide the needed
> binary.

LOL.  Managing data and compiling applications have nothing to do with
each other.  Try, try again.

You also don't seem to understand that this isn't as simple as
recompile.  It's not!!!!!!!!!!!  We clear on this?!  It's as simple as
needing to KNOW that you have to recompile and then KNOWING you have to
use a serious of obtuse options when compiling.

In other words, you seemingly know everything you don't know which is
more than the rest of us.

> Anyway, as I said, this really seems like the sort of thing that
> mostly gets done when someone sends in a patch.  So if it scratches
> your itch . . .
>
> > 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?!
>
> And it seems to me the distinction you're making is an invidious one.
> I am sick to death of so-called experts who want to blather on about
> this or that tuning parameter of [insert big piece of software here]
> without knowing the slightest thing about the basic operating
> environment.  A DBA has responsibility to know a fair amount about

In other words, you can't have a subject matter expert unless he is an
expert on every subject?  Ya, right!

> the platform in production.  A DBA who doesn't is one day going to
> find out what deep water is.

Agreed...as it relates to the database.  DBA's should have to know
details about the filesystem...that's the job of a SA.  You seem to be
under the impression that SA = DBA or somehow a DBA is an SA with extra
knowledge.  While this is sometimes true, I can assure you this is not
always the case.

This is exactly why large companies often have DBAs in one department
and SA in another.  Their knowledge domains tend to uniquely differ.

>
> > 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?
>
> Only if you were relying on it for backups, and suddenly your backups
> don't work.
>

Correction.  "Suddenly" your backends never worked.  Seems like it would
of been caught prior to going into testing.  Surely you're not
suggesting that people place a system into production without having
testing full life cycle?  Back up testing is part of your life cycle
right?

Greg