|From:||Kartyshov Ivan <i(dot)kartyshov(at)postgrespro(dot)ru>|
|Subject:||Re: [HACKERS] make async slave to wait for lsn to be replayed|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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;
> + 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.
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
|Next Message||Tom Lane||2020-03-27 01:26:49||Race condition in SyncRepGetSyncStandbysPriority|
|Previous Message||Alvaro Herrera||2020-03-27 00:41:21||Re: error context for vacuum to include block number|