Re: [HACKERS] make async slave to wait for lsn to be replayed
От | Alexander Korotkov |
---|---|
Тема | Re: [HACKERS] make async slave to wait for lsn to be replayed |
Дата | |
Msg-id | CAPpHfdswvdD6+TyyuJquBNvZU3Qn7PSGMvG2VgUBtF1Qcz0LQA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] make async slave to wait for lsn to be replayed (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: [HACKERS] make async slave to wait for lsn to be replayed
|
Список | pgsql-hackers |
On Tue, Aug 6, 2024 at 8:36 AM Michael Paquier <michael@paquier.xyz> wrote: > On Tue, Aug 06, 2024 at 05:17:10AM +0300, Alexander Korotkov wrote: > > The 0001 patch is intended to improve this situation. Actually, it's > > not right to just put RecoveryInProgress() after > > GetXLogReplayRecPtr(), because more wal could be replayed between > > these calls. Instead we need to recheck GetXLogReplayRecPtr() after > > getting negative result of RecoveryInProgress() because WAL replay > > position couldn't get updated after. > > 0002 patch comprises fix for the header comment of WaitLSNSetLatches() function > > 0003 patch comprises tests for pg_wal_replay_wait() errors. > > Before adding more tests, could it be possible to stabilize what's in > the tree? drongo has reported one failure with the recovery test > 043_wal_replay_wait.pl introduced recently by 3c5db1d6b016: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&dt=2024-08-05%2004%3A24%3A54 Thank you for pointing! Surely, I'll fix this before. ------ Regards, Alexander Korotkov Supabase
В списке pgsql-hackers по дате отправления: