AW: BUG #17393: Delete database after recovery with point-in-time is still missing datafiles
От | Lorenz, Christopher |
---|---|
Тема | AW: BUG #17393: Delete database after recovery with point-in-time is still missing datafiles |
Дата | |
Msg-id | b794d37a253944cf977d405ac579c233@ZIT-BB.Brandenburg.de обсуждение исходный текст |
Ответ на | BUG #17393: Delete database after recovery with point-in-time is still missing datafiles (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #17393: Delete database after recovery with point-in-time is still missing datafiles
|
Список | pgsql-bugs |
Hello, I created a script which do the complete procedure of create database backup and reproduce the bug while recovery. I created this used by rpm from official postgresql yum repo. I used a RedHat 7 OS. I also add the output of the script. You need to set your path to binary in the script: Line 9 pg_bin, as described before I also can reproduce this behaviorin Versions 12 to 14 The line with the wrong stop in bug report seams to be a copy&paste error and was done correctly. The WAL recovery is done by recovery_command which restores all previous saved files. In the log you can see that the WALfiles are used for recovery: 2022-03-29 10:30:19.686 CEST [15169] LOG: restored log file "000000010000000000000003" from archive 2022-03-29 10:30:19.727 CEST [15169] LOG: recovery stopping before commit of transaction 486, time 2022-03-29 10:30:08.739965+02 2022-03-29 10:30:19.727 CEST [15169] LOG: pausing at the end of recovery Regards, Christopher Lorenz -----Ursprüngliche Nachricht----- Von: Julien Rouhaud <rjuju123@gmail.com> Gesendet: Sonntag, 6. März 2022 08:42 An: Lorenz, Christopher <Christopher.Lorenz@ZIT-BB.Brandenburg.de>; pgsql-bugs@lists.postgresql.org Betreff: Re: BUG #17393: Delete database after recovery with point-in-time is still missing datafiles ... I can't reproduce the problem. Now, given what you seem to be using, this is likely an operator error: ... > pg_ctl -D $PGDATAstop this won't stop the instance. If that's what you're really doing it's clearly going to be broken. ... no WAL recovery? I recommend reading https://www.postgresql.org/docs/current/continuous-archiving.html to see what are the correct steps to restore a PITR backup, and if you still have a problem please show a script that is self contained (ie. provide all parameter initialization), safe, and actually works.
Вложения
В списке pgsql-bugs по дате отправления: