Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server
Дата
Msg-id CAB7nPqRhHAXA_fAnOOrwbHR5sVf=4Lo46V1bi4zFQ9XCMHdchQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server  (Michael Paquier <michael.paquier@gmail.com>)
Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
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.

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Small patch for pg_basebackup argument parsing
Следующее
От: AP
Дата:
Сообщение: Re: [HACKERS] pgsql 10: hash indexes testing