PostgreSQL systemd config scheme change

[Pavel Raiskup]

On Monday 07 of July 2014 15:57:30 Lennart Poettering wrote:
> On Mon, 07.07.14 14:48, Pavel Raiskup (praiskup at redhat.com) wrote:
> > > I'd always advise against inventing addition configuration files that
> > > are neither the daemons own, nor systemd's.
> >
> > I hope we can call this as a systemd's configuration, or no?  It sounds
> > like EnvironmentFile is also starting to be deprecated, is it so?
>
> No. Things you pull in via EnvironmentFile= are not systemd's
> configuration file. They are something you defined.

I defined the _place_ where the systemd's configuration is placed.  Truth.

> > The first neat benefit about this is that the configuration file may be
> > sourced by any shell script.  The second benefit is that user doesn't need
> > to bother with so long directory names:
> >
> >   $ cat /etc/systemd/system/postgresql at com.example.d/redef_sth.conf
> >   [service]
> >   Environ=PGDATA=_Pathname_without_spaces_
>
> Honestly, the right fix of this is to simply turn these two env vars
> into proper, native postgresql configuration directives, and then not
> invent anything new. Actually, aren't they proper, native postgresql
> configuration directives anyway? i mean, there's the "port" setting in
> postgresql.conf if I google for it. Seems to have something for PGDATA
> as well.

How I understand the PostgreSQL intentions, its complete and extensive
configuration tends to be moved to database itself.  So any other info
than PGDATA is not in our interest.  Tom is in loop but I would guess
that standardizing path to file where PGDATA is configured is not
something worth specifying upstream..

You use PGDATA to init/upgrade/check database..  cross any platform.  And
for multiple instances of PostgreSQL server you need to have easy way how
to specify PGDATA (which is our task now).

And, yes, one of my intentions is to move configuration of PGPORT into
postgresql.conf directly (which is quite easily possible).

> With that in place you could just make this a template service that
> simply invokes postgresql with a different configuration file derived
> from the instance name:
>
> postgresql at .service:
>
>         [Service]
>         ExecStart=/usr/sbin/postgres -c config_file=/etc/postgres/postgresql-%i.conf
>
> Then, people can just place their own postgresql.conf file with their
> individual settings in /etc/potsgres/postgresql-foobar.conf and simply
> enable, disable, start stop the instnace with that configuration file with:
>
> systemctl enable postgresql at foobar.service
> [...]
>
> This way you need no hack environment variable files or settings or
> anything, everything is just natural with native configuration
> directives.

See above (this way I think it would be too against PG upstream).

> > Little off-topic, but imo worth saying.  What I think we miss in systemd
> > in this regard is (because there are some convenience scripts trying to
> > automatize usual admin's tasks - and these are dependant on systemd's
> > configuration):
> >
> >   * Automatic way of exporting service's environment.  Something like:
> >
> >     $ systemctl environment postgresql.service
> >     PGDATA=/path/to/a/data/dir
> >     PGPORT=5433
> >
> >     The 'systemctl show -p Environment' does not work for us, because it
> >     does not expand contents of EnvironmentFile :(.  Also white-space
> >     problems ..
>
> What's the usecase? (not really against this, just want to hear the
> precise usecase)

You can look e.g. at postgresql-setup script (in Fedora's
postgresql-server package).  That script needs to know the PGDATA place -
and currently we need to parse the 'show -p Environment' output.

Pavel