On 15.01.2020 01:53, Andres Freund wrote:
On 2020-01-12 16:18:38 +0500, Andrey Borodin wrote:
11 янв. 2020 г., в 7:34, Bruce Momjian <br...@momjian.us> написал(а):
Actually, it might be worse than that. In my reading of
RecordTransactionCommit(), we do this:
write to WAL
flush WAL (durable)
make visible to other backends
replicate
communicate to the client
I think this means we make the transaction commit visible to all
backends _before_ we replicate it, and potentially wait until we get a
replication reply to return SUCCESS to the client.
No. Data is not visible to other backend when we await sync rep.
Yea, as the relevant comment in RecordTransactionCommit() says;
* Note that at this stage we have marked clog, but still show as
running
* in the procarray and continue to hold locks.
*/
if (wrote_xlog && markXidCommitted)
SyncRepWaitForLSN(XactLastRecEnd, true);
But it's worthwhile to emphasize that data at that stage actually *can*
be visible on standbys. The fact that the transaction still shows as
running via procarray, on the primary, does not influence visibility
determinations on the standby.
In common case, consistent reading in cluster (even if remote_apply is
on) is available (and have to be) only on master node. For example, if
random load balancer on read-only queries is established above master
and sync replicas (while meeting remote_apply is on) it's possible to
catch the case when preceding reads would return data that will be
absent on subsequent ones.
Moreover, such visible commits on sync standby are not durable from the
point of cluster view. For example, if we have two sync standbys then
under failover we can switch master to sync standby on which waiting
commit was not replicated but it was applied (and visible) on other
standby. This switching is completely safe because client haven't
received acknowledge on commit request and that transaction is in
indeterminate state, it can be as committed so aborted depending on
which standby will be promoted.
--
Best regards,
Maksim Milyutin
