From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_stop_backup(wait_for_archive := true) on standby server |
Date: | 2017-07-05 07:57:20 |
Message-ID: | CAB7nPqRhHAXA_fAnOOrwbHR5sVf=4Lo46V1bi4zFQ9XCMHdchQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 5, 2017 at 10:19 AM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | AP | 2017-07-05 09:31:40 | Re: pgsql 10: hash indexes testing |
Previous Message | Michael Paquier | 2017-07-05 06:32:36 | Re: Small patch for pg_basebackup argument parsing |