On Wed, Jul 5, 2017 at 4:57 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Wed, Jul 5, 2017 at 10:19 AM, Masahiko Sawada <sawada.mshk@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.
I agree with this idea. I've tried to make it wait for archiving but
it seems to me that there are other two issues we need to deal with:
the timeline ID on standby server is always reset after created a
restart point, and ThisTimeLineID variable of a backend process is not
set on the standby node when initializing. The former would be easy to
fix because resetting it is for debugging purposes. However, to deal
with latter issue, I'm considering the influence on other things.
> 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..
Yeah, I understood.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center