PostgreSQL & recovery.confAccording to the documentation for the upcoming version 12, the
recovery.conffile has gone! The release note states it clearly: the server will not start if
recovery.confis in place and all the configuration parameters have moved to the classic
postgresql.conf(or included files).
The change proposal is quite old, but represents a deep change in the way PostgreSQL handles the server startup and recovery and could take a while to get all the software out there to handle it too.
Please note that since PostgreSQL 12 is still in beta, things could change a little, even if the discussion and the implementation is nearly ended.
Two files can be created to instrument a standby node:
standby.signalif present in the
PGDATAdirectory the host will work as a standby, that is it will wait for new incoming WAL segments and replay them for the rest of its life;
recovery.signalif present will stop the WAL replaying as soon as all the WALs have been consumed or the
recovery_targetparameter has been reached.
It is interesting to note that
standby.signaltakes precedence on
recovery.signal, meaning that if both file exists the node will act as a standby. Both files may be empty, they act now as as triggering files rather than configuration files (here the change in the suffix).
So, what is the rationale for this change? There are several reasons, including the not needing for a duplication of configuration files. But what I like the most is that having the parameters into the trunk configuration make them good candidate to be changed via an
ALTER SYSTEMand the
postgresql.auto.confmachinery (see later for an example).
While all recovery parameters have been kept the same, the
trigger_fileone has been renamed to
promote_trigger_fileto clearly emphasize its meaning.
The above is not the only big difference in recovery handling: now it is no more possible to specify multiple
recovery_target_xxxvariables and “hope” to get the server to do it right (selecting the last one, effectively). The administrator is required to do a better job in selecting precisely which target to recover to! Last, also the timeline defaults to recover to the last one and not the current one.
As you can expect,
pg_basebackuphas been changed accordingly and therefore the
-R) now only puts a
standby.signalfile within the
PGDATAdirectory. Settings are now appended to
So, a lot of changes in the way the cluster manages the recovery/stand-by modes, and I hope all the automated backup software out there will respond properly.
ContextsContexts of the included setting GUCs have not changed so far:
template1=# SELECT name, context FROM pg_settings WHERE category like '% Archiv%'; name | context -------------------------|------------ archive_cleanup_command | sighup archive_command | sighup archive_mode | postmaster archive_timeout | sighup recovery_end_command | sighup restore_command | postmaster
What happens if you keep around
Let’s try it:
as already detailed, the database refuses to start.
% sudo -u postgres touch /pgdata/12beta2/recovery.conf % sudo -u postgres pg_ctl -D /pgdata/12beta2 start ... FATAL: using recovery command file "recovery.conf" is not supported LOG: startup process (PID 5837) exited with exit code 1 LOG: aborting startup due to startup process failure LOG: database system is shut down
What does happen when you issue an
Easy pal, configuration is put on
that results in:
% psql -U postgres template1 psql (12beta2) Type "help" for help. template1=# ALTER SYSTEM SET restore_command TO 'cp %p %f'; ALTER SYSTEM
% sudo cat /pgdata/12beta2/postgresql.auto.conf # Do not edit this file manually! # It will be overwritten by the ALTER SYSTEM command. restore_command = 'cp %p %f'