Re: unite recovery.conf and postgresql.conf - Mailing list pgsql-hackers

From Robert Haas
Subject Re: unite recovery.conf and postgresql.conf
Date
Msg-id CA+TgmoYkqFDAE219UXzQv=5Z6MvgkaxOTsA0Lz2JeAohoDojZA@mail.gmail.com
Whole thread Raw
In response to Re: unite recovery.conf and postgresql.conf  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On Wed, Dec 14, 2011 at 8:56 PM, Josh Berkus <josh@agliodbs.com> wrote:
> So for streaming replication, will I need to have a standby.enabled
> file, or will there be a parameter in postgresql.conf (or included
> files) which controls whether or not that server is a standby, available?
>
> In the best of all possible worlds, I'd really like to have a GUC which
> 100% controls whether or not the current server is a standby.

I think that would be a bad idea, because then how would pg_ctl
promote work?  It'd have to permanently change the value of that GUC,
which means rewriting a postgresql.conf file with an arbitrary forest
of comments and include files, and we can't do that now or, probably,
ever.  At least not reliably enough for this kind of use case.  I
think what Greg is going for is this:

1. Get rid of recovery.conf - error out if it is seen
2. For each parameter that was previously a recovery.conf parameter,
make it a GUC
3. For the parameter that was "does recovery.conf exist?", replace it
with "does standby.enabled exist?".

IMHO, as Greg says, that's as much change as we can cope with in one release.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Command Triggers
Next
From: Simon Riggs
Date:
Subject: Re: Race condition in HEAD, possibly due to PGPROC splitup