Re: unite recovery.conf and postgresql.conf

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Simon Riggs <simon(at)2ndquadrant(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-15 14:37:58
Message-ID: 10986.1316097478@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fujii Masao <masao(dot)fujii(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2011-09-15 14:44:43 psql setenv command
Previous Message Fujii Masao 2011-09-15 14:32:06 Re: unite recovery.conf and postgresql.conf