Re: make async slave to wait for lsn to be replayed

Ants Aasma писал 2017-10-26 17:29:
> On Mon, Oct 23, 2017 at 12:29 PM, Ivan Kartyshov
> <i(dot)kartyshov(at)postgrespro(dot)ru> wrote:
>> Ants Aasma писал 2017-09-26 13:00:
>>>
>>> Exposing this interface as WAITLSN will encode that visibility order
>>> matches LSN order. This removes any chance of fixing for example
>>> visibility order of async/vs/sync transactions. Just renaming it so
>>> the token is an opaque commit visibility token that just happens to
>>> be
>>> a LSN would still allow for progress in transaction management. For
>>> example, making PostgreSQL distributed will likely want timestamp
>>> and/or vector clock based visibility rules.
>>
>>
>> I'm sorry I did not understand exactly what you meant.
>> Please explain this in more detail.
>
> Currently transactions on the master become visible when xid is
> removed from proc array. This depends on the order of acquiring
> ProcArrayLock, which can happen in a different order from inserting
> the commit record to wal. Whereas on the standby the transactions will
> become visible in the same order that commit records appear in wal.
> The difference can be quite large when transactions are using
> different values for synchronous_commit. Fixing this is not easy, but
> we may want to do it someday. IIRC CSN threads contained more
> discussion on this topic. If we do fix it, it seems likely that what
> we need to wait on is not LSN, but some other kind of value. If the UI
> were something like "WAITVISIBILITY token", then we can later change
> the token to something other than LSN.
>
> Regards,
> Ants Aasma

It sounds reasonable. I can offer the following version.

WAIT LSN lsn_number;
WAIT LSN lsn_number TIMEOUT delay;
WAIT LSN lsn_number INFINITE;
WAIT LSN lsn_number NOWAIT;

WAIT [token] wait_value [option];

token - [LSN, TIME | TIMESTAMP | CSN | XID]
option - [TIMEOUT | INFINITE | NOWAIT]

Ready to listen to your suggestions.

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