Ants Aasma писал 2017-10-26 17:29:
On Mon, Oct 23, 2017 at 12:29 PM, Ivan Kartyshov
<i.kartys...@postgrespro.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
