Re: [HACKERS] Linux Largefile Support In Postgresql RPMS

From: Andrew Sullivan <andrew(at)libertyrms(dot)info>
To: PostgresSQL General Mailing List <pgsql-general(at)postgresql(dot)org>, PostgresSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Linux Largefile Support In Postgresql RPMS
Date: 2002-08-12 16:40:14
Message-ID: 20020812124014.O17166@mail.libertyrms.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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.

> 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.

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
the platform in production. A DBA who doesn't is one day going to
find out what deep water is.

> 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.

A

--
----
Andrew Sullivan 87 Mowat Avenue
Liberty RMS Toronto, Ontario Canada
<andrew(at)libertyrms(dot)info> M6K 3E3
+1 416 646 3304 x110

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Andrew Sullivan 2002-08-12 16:48:10 Re: [HACKERS] Linux Largefile Support In Postgresql RPMS\
Previous Message Oliver Elphick 2002-08-12 16:25:03 Re: [HACKERS] Linux Largefile Support In Postgresql RPMS

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Sullivan 2002-08-12 16:48:10 Re: [HACKERS] Linux Largefile Support In Postgresql RPMS\
Previous Message Greg Copeland 2002-08-12 16:30:12 Re: OOP real life example (was Re: Why is MySQL more