[Pkg-postgresql-private] Replacing cluster_ports by something better

Oliver Elphick olly@lfix.co.uk
Sun, 23 Jan 2005 23:19:51 +0000


On Sun, 2005-01-23 at 19:19 +0100, Martin Pitt wrote:
> Hi!
> 
> I currently try to make the PostgreSQL 8.0 packages actually install
> and start properly, so I work on a postgresql-common init script which
> starts up all configured postmasters. During this I thought about
> the current /etc/postgresql/cluster_ports, which I have some problems
> with:
> 
> 1. Why do we need  (potentially) several postmaster instances for one
>    major version in the first place? Having two system-wide 8.0
>    postmasters does not make sense, and if users want to run their own
>    private postmaster on their own database directory, then they
>    cannot use the system-wide infrastructure anyway, because this
>    would require root privileges.
> 
>    AFAICS we should stick to managing exactly one postmaster instance
>    per installed major version, which would greatly simplify the
>    architecture. 
> 
>    Sorry for discussing this so late, but I never really thought about
>    this before actually working on psql 8.

The point is to support ISPs and such who want to run multiple instances
under different ownerships.  This is a feature of the upstream package
that we currently make unavailable by our choice of configuration.  The
cluster_ports implementation makes it possible to control that centrally
rather than having to have each user doing his own management.  That is
especially a problem at system shutdown; we want to avoid having SIGKILL
sent to users' postmasters.

I think it would be a boost for spreading use of Pg amongst ISPs -- who
we hope would choose PG in preference to MySQL -- if their configuration
problems could be greatly reduced.

> 2. cluster_ports is currently a configuration file, and as such we
>    must be _very_ careful in automatically modifying it at e. g.
>    package installation.

Yes; but that's life.

> 3. cluster_ports contains a lot of redundancy, which should be
>    avoided:
> 
>    CLUSTER: not necessary _if_ we only support one instance (see 1.)
>    STATUS: this is okay
>    OWNER: should always be postgres
>    VERSION: already in CLUSTERPATH/PG_VERSION
>    PORT: already in CLUSTERPATH/postmaster.conf
>          (== /etc/postgresql/VERSION/postmaster.conf)
>    CLUSTERPATH: this seems okay to me, too

But the configuration can also be used to set up the databases.  Also,
the data needs to be available to clients who don't have privilege to
access $PG_DATA, since they have to know what port to connect to for
which database.  If we were only talking about the server side you would
be right.

> Proposal:
> ---------
> 
> If we support just one cluster per major version, we rely on the
> existence of /etc/postgresql/$MAJOR_VERSION/, in the case of several
> clusters we rely on /etc/postgresql/$CLUSTERNAME/. This directory
> contains all configuration files.
> 
> cluster_ports will be dropped entirely; instead, the relevant data
> (STATUS and CLUSTERPATH) is put into a new conffile
> /etc/postgresql/$CLUSTER/status and a symlink
> /etc/postgresql/$CLUSTER/pgdata which points to the actual data
> directory.

As I point out above, this doesn't handle the problem of client access
and I also wish to support multiple independent postmasters for
different users.  If that is really impracticable, it will have to be
dropped, but at the moment I don't see that it is.

> The purpose user_clusters seems to be sensible to me, so I would just
> leave it as it is by now. However, what is GROUP for?
> 

GROUP is to configure access for members of Unix groups.

-- 
Oliver Elphick                                          olly@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
GPG: 1024D/A54310EA  92C8 39E7 280E 3631 3F0E  1EC0 5664 7A2F A543 10EA
                 ========================================
   Do you want to know God?   http://www.lfix.co.uk/knowing_god.html