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
