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
Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server |
Список | 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 по дате отправления: