Re: Disallow cancellation of waiting for synchronous replication

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 <bruce@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