On Mon, Oct 30, 2017 at 7:25 PM, Ivan Kartyshov <i.kartys...@postgrespro.ru> wrote: > 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.
Making the interface more specific about the mechanism is not what I had in mind, quite the opposite. I would like to see the interface describe the desired effect of the wait. Stepping back for a while, from what I understand the reason we want to waiting is to prevent observation of database state going backwards. To limit the amount of waiting needed we tell the database what we have observed. For example "I just observed my transaction commit", or "the last time I observed state was X", and then have the database provide us with a snapshot that is causally dependent on those states. This does not give us linearizability, for that we still need at the very least serializable transactions on standby. But it seems to provide a form of sequential consistency, which (if it can be proved to hold) makes reasoning about concurrency a lot nicer. For lack of a better proposal I would like something along the lines of: WAIT FOR state_id[, state_id] [ OPTIONS (..)] And to get the tokens maybe a function pg_last_commit_state(). Optionally, to provide read-to-read causality, pg_snapshot_state() could return for example replay_lsn at the start of the current transaction. This makes sure that things don't just appear and disappear when load balancing across many standby servers. WAIT FOR semantics is to ensure that next snapshot is causally dependent (happens after) each of the specified observed states. The state_id could simply be a LSN, or to allow for future expansion something like 'lsn:0000/1234'. Example extension would be to allow for waiting on xids. On master that would be just a ShareLock on the transactionid. On standby it would wait for the commit or rollback record for that transaction to be replayed. Robert made a good point that people will still rely on the token being an LSN, but perhaps they will be slightly less angry when we explicitly tell them that this might change in the future. Regards, Ants Aasma  https://www.postgresql.org/docs/devel/static/functions-admin.html#functions-snapshot-synchronization -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers