Re: [HACKERS] Last call?

"Thomas G. Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> ... which I've now done for the admin guide. This contains a chapter on
> installation which is from the same source as the text-only version to
> be put in INSTALL.
> Could folks look it over and in particular make sure that it is an
> acceptable substitute for what is now in INSTALL?

A couple minor comments:

1. I think the disk space estimates are now too low. Yesterday I
measured the required space to build/install/do regression test on an
HPUX 10.20 box, which is probably not too unrepresentative of RISC-type
workstations. The source tree got up to 29600K, the installed code +
initdb took about 4600K, and the regression test database occupied
18500K. Furthermore, I did not build Tcl, Perl, or ODBC libraries,
which would certainly have increased the build space and installed code
size by a few more megs. Still more: the source tree included the
formatted doc files (those tar.gz files in doc/) that are currently in
the CVS server. I assume that 6.4's formatted doc files will be
substantially bulkier, thanks to Thomas' tireless efforts ;-). And
still more: I didn't do an install of the documentation files. So you
need to add whatever the installed footprint of the html, ps, and
man-page files are.

The estimates given in the INSTALL docs (45MB peak usage during build &
install, 3MB permanent footprint) are probably at least 50% too low.
We've been busy little builders, evidently :-).

It's probably not necessary to repeat the disk space estimates twice,
either. Step 3a of the install procedure ought to be merged into the
"Requirements to run Postgres" section.

2. In install step 2 ("Create the Postgres superuser account...")
it wouldn't hurt to add "The owner of the Postgres files can be any
unprivileged user account. It MUST NOT be root, bin, or any other
account with special access rights, as that would create a security risk."
This point is made later, but the time that an installer needs to know
it is right here.

3. In step 6 (dumping your old database) I think that the dumpall
command should include -z:
$ src/bin/pg_dump/pg_dumpall -z > db.out
Otherwise table ownership will not be preserved, which could ruin
someone's day. (BTW, is there really any value in extracting the
pg_dumpall script from the distribution as shown? Most of the problems
we've fixed in database dumping have been inside pg_dump, methinks.
So it's not clear that this contortion helps anything.)

4. (I mentioned this one already.) Step 19a (start postmaster,
as a substep of running the regression tests) probably ought to be
a top-level step between 18 and 19. You want people to do it even
if they skip the regression test.

regards, tom lane