On Mon, Apr 1, 2024 at 5:25 AM Bharath Rupireddy < bharath.rupireddyforpostg...@gmail.com> wrote:
> On Mon, Apr 1, 2024 at 5:54 AM Alexander Korotkov <aekorot...@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
v17-0001-Implement-pg_wal_replay_wait-stored-procedure.patch
Description: Binary data
