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

It would be nice to get all that addressed in 10. Thoughts?

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to