On Mon, Aug 12, 2002 at 11:17:31AM -0500, Greg Copeland wrote:
>
> And, what if he just remounted it read only. Mistakes will happen.
> That doesn't come across as being a strong argument to me. Besides,
> it's doubtful that a filesystem is going to be remounted while it's in
> use. Which means, these issues are going to be secondary to actual
> product use of the database. That is, either the system is working
> correctly or it's not. If it's not, guess it's not ready for production
> use.
If it's already in production use, but was taken out briefly for
maintenance, and the supposed expert SAs do something dimwitted, then
it's broken, sure. The point I was trying to make is that the
symptoms one sees from breakage can be from many different places,
and so a glib "enable largefile support" remark hides an actual,
real-world complexity. Several steps can be broken, any one fof
which causes problems. Better to force the relevant admins to do the
work to set things up for an exotic feature, if it is desired.
There's nothing about Postgres itself that requires large file
support, so this is really a discussion about pg_dump. Using split
is more portable, in my view, and therefore preferable. You can also
use the native-compressed binary dump format, if you like one big
file. Both of those already work out of the box.
> > There are, in any case, _lots_ of problems with these large files.
> All of those are SA issues.
So is compiling the software correctly, if the distinction has any
meaning at all. When some mis-installed bit of software breaks, the
DBAs won't go running to the SAs. They'll ask here.
A
--
----
Andrew Sullivan 87 Mowat Avenue
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M6K 3E3
+1 416 646 3304 x110
