Re: Disallow cancellation of waiting for synchronous replication

From: Andres Freund <andres(at)anarazel(dot)de>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Maksim Milyutin <milyutinma(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-14 22:53:18
Message-ID: 20200114225318.huir7mtrmu526kgf@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

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.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-01-14 22:54:16 Re: aggregate crash
Previous Message Andrew Dunstan 2020-01-14 22:50:32 Re: Unicode escapes with any backend encoding