Re: [HACKERS] 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
>  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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers