Skip site navigation (1) Skip section navigation (2)

Changing recovery.conf parameters into GUCs

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Changing recovery.conf parameters into GUCs
Date: 2013-03-28 15:48:59
Message-ID: CA+U5nMKyuDxr0=5PSen1DZJndauNdz8BuSREau=ScN-7DZ9acA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
What we want to do is make recovery parameters into GUCs, allowing
them to be reset by SIGHUP and also to allow all users to see the
parameters in use, from any session.

The existing mechanism for recovery is that
1. we put parameters in a file called recovery.conf
2. we use the existence of a recovery.conf file to trigger archive
recovery/replication

I also wish to see backwards compatibility maintained, so am proposing
the following:

a)  recovery parameters are made into GUCs (for which we have a patch
from Fujii)
b)  all processes automatically read recovery.conf as the last step in
reading configuration files, if it exists, even if data_directory
parameter is in use (attached patch)
c)  we trigger archive recovery by the presence of either
recovery.conf or recovery.trigger in the data directory. At the end,
we rename to recovery.done just as we do now. This means that any
parameters put into recovery.conf will not be re-read when we SIGHUP
after end of recovery. Note that recovery.trigger will NOT be read for
parameters and is assumed to be zero-length.
(minor patch required)

This allows these use cases

1. Existing users create $PGDATA/recovery.conf and everything works as
before. No servers crash, because the HA instructions in the wiki
still work. Users can now see the parameters in pg_settings and we can
use SIGHUP without restarting server. Same stuff, new benefits.

2. New users wish to move their existing recovery.conf file to the
config directory. Same file contents, same file name (if desired),
same behaviour, just more convenient location for config management
tools. Recovery is triggered by recovery.trigger in $PGDATA. Trigger
and configuration are now separate, if desired.

3. Split mode. We can put things like trigger_file into the
postgresql.conf directory and also put other parameters (for example
PITR settings) into recovery.conf. Where multiple tools are in use, we
support both APIs.

Specific details...

* primary_conninfo, trigger_file and standby_mode are added to
postgresql.conf.sample
* all ex-recovery.conf parameters are SIGHUP, so no errors if
recovery.conf has changed to .done

If desired, this behaviour could be enabled by a parameter called
recovery_conf_enabled = on (default). When set to off, this would
throw an error if recovery.conf exists. (I don't see a need for this)

The patch to implement this is very small (attached). This works
standalone, but obviously barfs at the actual parameter parsing stage.
Just in case it wasn't clear, this patch is intended to go with the
parts of Fujji's patch that relate to GUC changes.

If we agree, I will merge and re-post before commit.

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

Attachment: read_recovery.conf_from_data_directory.v1.patch
Description: application/octet-stream (6.0 KB)

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2013-03-28 15:54:59
Subject: Re: FDW for PostgreSQL
Previous:From: Stephen FrostDate: 2013-03-28 15:24:42
Subject: Re: FDW for PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group