Hi hackers,

I'd like to share some thoughts on 'recovery.conf'-related variables.


Introduction
============

The 'recovery.conf' file is used to set up the recovery configuration of a 
PostgreSQL server. Its structure closely resembles that of the 
'postgresql.conf' file whose settings are written to the GUC (stands for Grand 
Unified Configuration) at startup. There are several variables in the 
PostgreSQL 
backend, e.g.,

* recoveryRestoreCommand
* recoveryEndCommand
* recoveryCleanupCommand
* recoveryTarget
  ...

that store values read from the 'recovery.conf' file during server startup. 
Although they represent the recovery configuration, they are not included in 
the GUC and thus are not directly accessible via SHOW. Furthermore, the lack 
of an iterable collection (i.e. sorted array of 'config_generic' structures) of 
these variables significantly complicates the 'readRecoveryCommandFile' 
procedure since it mainly consists of numerous string comparisons and variable 
assignments. Lastly, the 'recovery.conf' is not reloadable, which means that 
there is no way to change recovery settings (e.g. 'primary_conninfo') after 
startup. This feature could come in handy if, for example, a master-slave 
connection terminated not long after the master's password had been changed. 
There would be no need to restart the slave in that case.


Possible changes
================

There are at least two ways to faciliate the management of these variables:

1. Combine them into a set similar to the GUC and name it something like RUC 
(Recovery Unified Configuration), thus providing separate variable storage for 
each configuration file. Some of its members might be read-only.

2. Add them to the GUC, perhaps with a special context.

Both approaches would allow us to create, for example, a dedicated view for 
the 'recovery.conf' file using a drastically simplified procedure written in C. 
Also it would get easier to reload at least some settings from the 
'recovery.conf' file at runtime.

Suggestions and comments are welcome.

-- 
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to