Re: unite recovery.conf and postgresql.conf

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: unite recovery.conf and postgresql.conf
Date: 2011-09-20 07:39:29
Message-ID: CA+U5nM+oo_SN3skkrf=7NTQh=hpJgdXYy5k3b5cxfit8mZj99w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 16, 2011 at 1:13 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On fre, 2011-09-16 at 01:32 -0400, Tom Lane wrote:
>> As far as the other issues go, I think there is actually a
>> prerequisite
>> discussion to be had here, which is whether we are turning the
>> recovery
>> parameters into plain old GUCs or not.  If they are plain old GUCs,
>> then
>> they will presumably still have their values when we are *not* doing
>> recovery.  That leads to a couple of questions:
>> * will seeing these values present in pg_settings confuse anybody?
>
> How so?  We add or change the available parameters all the time.
>
>> * can the values be changed when not in recovery, if so what happens,
>>   and again will that confuse anybody?
>
> Should be similar to archive_command and archive_mode.  You can still
> see and change archive_command when archive_mode is off.

I do think special handling would be useful here, of some kind. We
could reset them as well, if we wished, but that is probably more
trouble than is worth.

Perhaps we need a new SCOPE attribute on pg_settings to show whether
the parameter applies in recovery, in normal or both.

>> * is there any security hazard from ordinary users being able to see
>>   what settings had been used?
>
> Again, not much different from the archive_* settings.  They are, after
> all, almost the same in the opposite direction.

There is a potential security hole if people hardcode passwords into
primary_conninfo. As long as we document not to do that, we're OK.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thom Brown 2011-09-20 07:47:27 Re: File not found error on creating collation
Previous Message Simon Riggs 2011-09-20 07:31:59 Re: unite recovery.conf and postgresql.conf