On Tue, Jul 30, 2013 at 6:40 PM, Josh Berkus <josh@agliodbs.com> wrote:
>
> On 07/30/2013 10:28 AM, Greg Stark wrote:> On Tue, Jul 30, 2013 at 6:10
> PM, Alvaro Herrera
>> Well more to the point, if we conf.d for sysadmins to drop in extra
>> snippets in a different place then we could drop conf.d in PGDATA
>> since there's no need for it any more and just have auto.conf in
>> PGDATA directly.
>
> That assumes that the only reason we have for a conf.d is to support
> auto.conf, which I don't agree with; I personally have a need for conf.d
> which has nothing to do with auto.conf.
No, wait. We had two reasons for conf.d and we thought we could kill
two birds with one stone. It seems it's turning out that we can't kill
both birds with the same stone because we want to separate the user
maintained config from the automatically maintained config even
further than just having them in separate files. Now we need them in
separate directories.
If you have a need for conf.d which has nothing to do with auto.conf
then you presumably will want to be editing the system conf.d which
might be in PGDATA or might be in /etc or might be someplace else. I
totally agree that conf.d is useful for sysadmins as well as for
distribution authors.
But if we're going to insist that conf.d be in PGDATA then I'm saying
we don't need a second conf.d just to contain that one file. And if we
let distributions and sysadmins drop files in there then we'll be back
to square 0 with wanting to separate them.
I guess what I'm saying is that auto.conf shouldn't be in conf.d after
all. It should just be in PGDATA directly and trying to kill two birds
with one stone led us astray. Putting it in conf.d creates a raft of
problems of what if conf.d is moved and what if it's shared between
databases and what if the user puts files that come after it, etc.
Putting it directly in PGDATA lets us manage those issues however we
want and ties the automatic file to a specific database regardless of
how we handle conf.d in the future.
> Also, see gsmith's point about forcing auto.conf to be in PGDATA as not
> satisfactory for Debian users (and others).
Greg Smith's argument was about recovery.conf which is a file that
users are expected to edit. A file which user's are not expected to
edit and is maintained by the software is no more a configuration file
than pg_auth or pg_database which are actually being stored in the
database itself.
Having an automatically maintained file and a manually maintained file
is going to raise some tricky problems. In Oracle they have exactly
the same issue. In that case the automatically maintained one is
actually kept in a binary format. You can dump it out in text format
but unless you switch which one you're using it doesn't read the text
format file at all. I assume they did this because working out the
conflicts between the two was just too complex for users.
I think we're fine with allowing users to use both but we should try
to keep the two as separate as possible to avoid confusion. Keeping
the auto.conf inside conf.d sounds like it will actually confuse users
about which files they're supposed to edit and which belong to the
system.
--
greg