Re: pg_stop_backup(wait_for_archive := true) on standby server

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

In response to

Responses

Browse pgsql-hackers by date

  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