As discussed in private:
On Debian, with pitrery 3.1 (from apt.dalibo.org or github) and PG 12, the behaviour has changed:
- with
pitrery restore, the postgresql.conf is modified (restore_command & others added) and is stored in restored_config_files
- so an immediate restart fails, because there is a
recovery.signal but no restore_command in /etc/postgresql/12/main/postgresql.conf or postgresql.auto.conf.
With PG11, a suitable recovery.conf is created and you can start PG immediately.
On CentOS and with PG12, the postgresql.conf is in PGDATA and is updated with restore_command, so an immediate start is possible.
I'd really prefer a clean postgresql.auto.conf with the same options as the old recovery.conf, that would solve this problem, and cleanly separate parameters added by pitrery from the original ones.
At least, as big warning should appear at the end of the restore if no postgresql.conf is present in PGDATA, explaining the operations left to the user (ie picking the useful lines or copying the postgresql.conf file from restored_config_files).
As discussed in private:
On Debian, with pitrery 3.1 (from apt.dalibo.org or github) and PG 12, the behaviour has changed:
pitrery restore, thepostgresql.confis modified (restore_command& others added) and is stored inrestored_config_filesrecovery.signalbut norestore_commandin/etc/postgresql/12/main/postgresql.conforpostgresql.auto.conf.With PG11, a suitable
recovery.confis created and you can start PG immediately.On CentOS and with PG12, the
postgresql.confis inPGDATAand is updated withrestore_command, so an immediate start is possible.I'd really prefer a clean
postgresql.auto.confwith the same options as the oldrecovery.conf, that would solve this problem, and cleanly separate parameters added by pitrery from the original ones.At least, as big warning should appear at the end of the restore if no
postgresql.confis present inPGDATA, explaining the operations left to the user (ie picking the useful lines or copying thepostgresql.conffile fromrestored_config_files).