Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change in behaviour while restoring, between PG 11 & 12 #113

Open
Krysztophe opened this issue May 12, 2020 · 0 comments
Open

Change in behaviour while restoring, between PG 11 & 12 #113

Krysztophe opened this issue May 12, 2020 · 0 comments
Labels

Comments

@Krysztophe
Copy link
Contributor

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).

@madtibo madtibo added the bug label Feb 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants