Re: unite recovery.conf and postgresql.conf

Fujii Masao <masao.fujii@gmail.com>

From: Fujii Masao <masao.fujii@gmail.com>

To: Joshua Berkus <josh@agliodbs.com>

Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Peter Eisentraut <peter_e@gmx.net>, Simon Riggs <simon@2ndquadrant.com>, Magnus Hagander <magnus@hagander.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>

Date: 2011-09-20T06:38:44Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Restructure error handling in reading of postgresql.conf.
- d56b3afc0376 9.2.0 cited

On Sat, Sep 17, 2011 at 4:22 AM, Joshua Berkus <josh@agliodbs.com> wrote:
>> that makes it look like one of the WAL archive transfer trigger
>> files,
>> which does not seem like a great analogy.  The pg_standby
>> documentation
>> suggests names like "foo.trigger" for failover triggers, which is a
>> bit
>> better analogy because something external to the database creates the
>> file.  What about "recovery.trigger"?

I'm OK with that name.

> Do we want a trigger file to enable recovery, or one to *disable* recovery?  Or both?

ISTM that only supporting a trigger file to enable recovery is less confusing.

>> * will seeing these values present in pg_settings confuse anybody?
>
> No.  pg_settings already has a couple dozen "developer" parameters which nobody not on this mailing list understands.  Adding the recovery parameters to it wouldn't confuse anyone further, and would have the advantage of making the recovery parameters available by monitoring query on a hot standby.

+1

>> * is there any security hazard from ordinary users being able to see
>>   what settings had been used?
>
> primary_conninfo could be a problem, since it's possible to set a password there.

True. I agree that primary_conninfo should be restricted to superuser.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center