PostgreSQL systemd config scheme change

[Lennart Poettering]

On Mon, 07.07.14 17:07, Pavel Raiskup (praiskup at redhat.com) wrote:

> 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.

Well, inventing some environemnt-block-style files and setting
EnvironmentFile= to them doesn't make that file a systemd configuration
file...

Again, I really wished you wouldn't dump three kinds of configuration
files on the admins: postgres' own, your own environment file (which
duplicates at leats the port thing you can also specify in the
configuration file), and systemds own.

With your scheme the admin would need to know and modify all three all
the time. I am simply suggesting you just stick to two: the
postgresql-specific one, and the systemd-specific one, but not another,
redundant one in the middle.

> > > 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..

Hmmm? I mean, if you insist that environment variables are a great way
to pass configuration around (which I strongly disgaree with, but well),
then sure go ahead, you can also do this:

    [Service]
    Environment=PGDATA=%I
    ExecStart=/usr/sbin/postgres

That way you pass thing through via the env block rather then arg
block. Not sure I understand why env vars would be better for this, but
well, whatever....

then, you can place the port configuration in that specific $PGDATA's
configuration file, and things are simple and easy.

> 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).

Well, 

      Environment=PGDATA=%I
      ExecStart=/usr/sbin/postgres

and

      ExecStart=/usr/sbin/postgres "-c config_file=%I"

Are pretty much identical in their effect. Choose either of them. I'd
take the latter, but if you are married to env vars, pick the former.

> > 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).

Would it? Why so?

Lennart

-- 
Lennart Poettering, Red Hat