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 CAPpHfdtGh9Gmx-O5qhcSGJmn5z7-yFb7NGqTrM2J94E14w8EOg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] make async slave to wait for lsn to be replayed  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Ответы Re: [HACKERS] make async slave to wait for lsn to be replayed  (Andy Fan <zhihuifan1213@163.com>)
Re: [HACKERS] make async slave to wait for lsn to be replayed  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
Дерево обсуждения
On Mon, Apr 1, 2024 at 5:25 AM Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote:
On Mon, Apr 1, 2024 at 5:54 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:
>
> > 9. To me the following query blocks even though I didn't mention timeout.
> > CALL pg_wal_replay_wait('0/fffffff');
>
> If your primary server is freshly initialized, you need to do quite
> data modifications to reach this LSN.

Right, but why pg_wal_replay_wait  blocks without a timeout? It must
return an error saying it can't reach the target LSN, no?

How can replica know this?  It doesn't look feasible to distinguish this situation from the situation when connection between primary and replica became slow.  I'd keep this simple.  We have pg_sleep_for() which waits for the specified time whatever it is.  And we have pg_wal_replay_wait() waits till replay lsn grows to the target whatever it is.  It's up to the user to specify the correct value.
 
Did you forget to attach the new patch?

Yes, here it is. 

------
Regards,
Alexander Korotkov 
Вложения

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

Предыдущее
От: Bertrand Drouvot
Дата:
Сообщение: Re: Introduce XID age and inactive timeout based replication slot invalidation
Следующее
От: Nisha Moond
Дата:
Сообщение: Re: Synchronizing slots from primary to standby