On Wed, Jul 5, 2017 at 10:19 AM, Masahiko Sawada <sawada.m...@gmail.com> wrote: > I feel that since we cannot switch the WAL forcibly on the standby > server we need to find a new way to do so. I'm not sure but it might > be a hard work and be late for PG10. Or you meant that you have a idea > for this?
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. In most workloads, multiple WAL segments can be generated per second, and in even more of them a new segment generated would happen in less than a minute, so waiting for a segment switch on the primary should not be a problem for most users. The log letting user know about the wait should be more informative when things happen on a standby, like "waiting for segment to be finished or switched on the primary". If the restriction approach is preferred, I think that the check should happen in do_pg_stop_backup as well, and not in pg_stop_backup_v2 as your patch suggests. pg_basebackup is not able to do non-exclusive backups but this may happen some day, who knows.. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
