Re: Requiring recovery.signal or standby.signal when recovering with a backup_label
От | Kyotaro Horiguchi |
---|---|
Тема | Re: Requiring recovery.signal or standby.signal when recovering with a backup_label |
Дата | |
Msg-id | 20230928.125851.2051261991058034791.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Requiring recovery.signal or standby.signal when recovering with a backup_label (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Requiring recovery.signal or standby.signal when recovering with a backup_label
Re: Requiring recovery.signal or standby.signal when recovering with a backup_label |
Список | pgsql-hackers |
At Fri, 10 Mar 2023 15:59:04 +0900, Michael Paquier <michael@paquier.xyz> wrote in > My apologies for the long message, but this deserves some attention, > IMHO. > > So, any thoughts? Sorry for being late. However, I agree with David's concern regarding the unnecessary inconvenience it introduces. I'd like to maintain the functionality. While I agree that InArchiveRecovery should be activated only if ArchiveReArchiveRecoveryRequested is true, I oppose to the notion that the mere presence of backup_label should be interpreted as a request for archive recovery (even if it is implied in a comment in InitWalRecovery()). Instead, I propose that we separate backup_label and archive recovery, in other words, we should not turn on InArchiveRecovery if !ArchiveRecoveryRequested, regardless of the presence of backup_label. We can know the minimum required recovery LSN by the XLOG_BACKUP_END record. The attached is a quick mock-up, but providing an approximation of my thoughts. (For example, end_of_backup_reached could potentially be extended to the ArchiveRecoveryRequested case and we could simplify the condition..) regards. -- Kyotaro Horiguchi NTT Open Source Software Center
Вложения
В списке pgsql-hackers по дате отправления: