On Wed, Jul 5, 2017 at 4:57 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > Why not refactoring a bit do_pg_stop_backup() so as the wait phase > happens even if a backup is started in recovery? Now wait_for_archive > is ignored because no wait is happening and the stop point is directly > returned back to the caller. For the wait actually happening, I don't > have a better idea than documenting the fact that enforcing manually a > segment switch on the primary needs to happen. That's better than > having users including WAL in their base backups but not actually > having everything they need. And I think that documenting that > properly is better than restricting things that should work.
While looking at that in more details, I got surprised by two things: 1) No backup history file is generated on a standby during a base backup. 2) Because of 1), those files are not archived even if archive_mode = always. This sounds to me like a missing optimization of archive_mode = always, and the following comment block in xlog.c is at least incorrect as an archiver can be invoked in recovery: * XXX currently a backup history file is for informational and debug * purposes only. It's not essential for an online backup. Furthermore, * even if it's created, it will not be archived during recovery because * an archiver is not invoked. So it doesn't seem worthwhile to write a * backup history file during recovery. So I would suggest the following things to address this issue: 1) Generate a backup history file for backups taken at recovery as well. 2) Archive it if archive_mode = always. 3) Wait for both the segment of the stop point and the backup history files to be archived before returning back to the caller of pg_stop_backup. It would be nice to get all that addressed in 10. Thoughts? -- Michael -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers