Installation - Mailing list pgsql-hackers

Okay, the crowd seemed to say that PostgreSQL is not really harder to
install than MySQL, but that it isn't easy either. My personal goal then
is to make the installation so easy that even people who don't even have
any data will download and install PostgreSQL just to see how smooth it
works. :-)

Seriously, the particular trouble points I could identify are both in
documentation and in implementation.


1) User account juggling

It is sometimes confusing to keep track when you need to log in as
who:
    > mkdir /usr/local/pgsql/data    > chown postgres /usr/local/pgsql/data    > su - postgres    >
/usr/local/pgsql/bin/initdb-D /usr/local/pgsql/data
 

This sort of stuff shouldn't be necessary. Perhaps it should just work
like this:
   root# adduser postgres   root# /usr/local/pgsql/bin/initdb -u postgres -D /usr/local/pgsql/data   root#
/usr/local/pgsql/bin/postmaster-D /usr/local/pgsql/data
 

If initdb is run as root it simply reexecutes itself as whatever -u said,
after having created the data directory and done the chown thing. It could
furthermore initialize the postgresql.conf file with a line `user =
$user'. That way the postmaster could also be started as root and setuid
itself after having read the configuration file, like Apache does.

This would require some code auditing, but it seems doable.


2) System specific problems

Users can expect to be told of platform-specific exceptions up front. "If
you have problems, look into doc/FAQ_xxx" is not nice. If it is known that
libpq++ doesn't build on platform X then that should be mentioned before
people ever run configure. "Might be different on your platform" is not
good. We know pretty well what platforms we run on, so we can also provide
accurate command lines.

There's a whole subculture of alternative installation instructions
existing in the various "FAQs", many of which are tendentially out of
date. Of course at the end it's also better to fix these problems rather
than documenting them.


3) Error conditions not documented

Okay, that simply needs to be done.


4) Backup & Restore

There's not much to be done about this requirement, but it could be
documented better and perhaps in different ways. For example, some people
might not want to install the new version over the old one, but rather run
both in parallel and transfer the data over then. (I'd do that in any
case.)

One premise is that people who upgrade already have an existing
installation, by definition, so they can also read the existing
documentation and already have existing knowledge about the backup
procedure. Therefore the Administrator's Guide should describe the
implicications of the possible backup and upgrade strategies before one
even looks at the installation instructions. The latter could then simply
say "by now you should have backed up your data" in a slightly more
verbose fashion rather than trying to cram the administrator's guide into
three sentences.


Some people were mentioning that the installation instructions should also
tell more about createuser and these things. I don't agree with that.
These sort of things should be covered in the tutorial or the
administrator's guide ("Database user and permission management", hard to
miss).


Does anyone have other ideas?

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden