Re: Disallow cancellation of waiting for synchronous replication

From: Maksim Milyutin <milyutinma(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Disallow cancellation of waiting for synchronous replication
Date: 2020-01-15 10:49:35
Message-ID: 10cff645-b3b0-68c4-3e14-59bcf2717e3d@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)momjian(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2020-01-15 11:57:37 Re: [HACKERS] Block level parallel vacuum
Previous Message Fabien COELHO 2020-01-15 10:21:36 Re: [PATCH v1] pg_ls_tmpdir to show directories