Re: unite recovery.conf and postgresql.conf

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

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

Cc: 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-15T14:37:58Z

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

Fujii Masao <masao.fujii@gmail.com> writes:
> It seems to need a bit more time until we've reached a consensus about
> the treatment of recovery.conf. How about committing the core patch
> first, and addressing the recovery.conf issue as a different patch later?

> The attached patch provides a core part of the feature, i.e., it moves
> every recovery parameters from recovery.conf to postgresql.conf.
> Even if you create recovery.conf, the server doesn't read it automatically.

> The patch renames recovery.conf to recovery.ready, so if you want to
> enter archive recovery or standby mode, you need to create
> recovery.ready file in the cluster data directory. Since recovery.ready is
> just a signal file, its contents have no effect.

This seems like it's already predetermining the outcome of the argument
about recovery.conf.  Mind you, I'm not unhappy with this choice, but
it's hardly implementing only behavior that's not being debated.

If we're satisfied with not treating recovery-only parameters different
from run-of-the-mill GUCs, this is fine.

			regards, tom lane