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
