Re: Disabling auto.conf WAS: Turning recovery.conf into GUCs

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alex Shulgin <ash(at)commandprompt(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Disabling auto.conf WAS: Turning recovery.conf into GUCs
Date: 2014-11-24 20:05:57
Message-ID: 54738FA5.4070103@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/24/2014 07:29 AM, Stephen Frost wrote:
>> > > > Sigh, here we go again. I don't think you can disable postgresql.auto.conf
>> > > > in the current code. As I recall, the argument was that it's harder to
>> > > > diagnose problems if postgresql.auto.conf takes effect in some system
>> > > > but not others.
>> >
>> > I don't buy this at all. What's going to be terribly confusing is to
>> > have config changes start happening for users who are managing their
>> > configs through a CM (which most should be..). ALTER SYSTEM is going to
>> > cause more problems than it solves.

The main reason why disabling auto.conf was found not to be worthwhile
is that anyone with superuser rights can *already* change the config by
using ALTER DATABASE and ALTER ROLE, and that's a LOT less auditable
than pg.auto.conf is. Heck, we don't even have a good system view for
SET parameters on DB objects.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christoph Berg 2014-11-24 20:08:24 Re: test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)
Previous Message Josh Berkus 2014-11-24 20:02:52 Re: Turning recovery.conf into GUCs