Re: [HACKERS] make async slave to wait for lsn to be replayed

Anna, thank you for your review.

On 2020-03-25 21:10, Anna Akenteva wrote:
> On 2020-03-21 14:16, Kartyshov Ivan wrote:
>> and event is:
>> LSN value [options]
>> TIMESTAMP value
> I would maybe remove WAIT FOR TIMESTAMP. As Robert Haas has pointed
> out, it seems a lot like pg_sleep_until(). Besides, it doesn't
> necessarily need to be connected to transaction start, which makes it
> different from WAIT FOR LSN - so I wouldn't mix them together.
I don't mind.
But I think we should get one more opinions on this point.

> ===
> This is how WaitUtility() is called - note that time_val will always be
> > 0:
> +    if (time_val <= 0)
> +        time_val = 1;
> +...
> +    res = WaitUtility(lsn, (int)(time_val * 1000), dest);
>
> (time_val * 1000) is passed to WaitUtility() as the delay argument.
> And inside WaitUtility() we have this:
>
> +if (delay > 0)
> +    latch_events = WL_LATCH_SET | WL_TIMEOUT | WL_POSTMASTER_DEATH;
> +else
> +    latch_events = WL_LATCH_SET | WL_POSTMASTER_DEATH;
>
> Since we always pass a delay value greater than 0, we'll never get to
> the "else" clause here and we'll never be ready to wait for LSN
> forever. Perhaps due to that, the current test outputs this after a
> simple WAIT FOR LSN command:
> psql:<stdin>:1: NOTICE:  LSN is not reached.
I fix it, and Interruptions in last patch.

Anna, feel free to work on this patch.

--
Ivan Kartyshov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company