Re: Disallow cancellation of waiting for synchronous replication - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Disallow cancellation of waiting for synchronous replication
Date
Msg-id 20200114225318.huir7mtrmu526kgf@alap3.anarazel.de
Whole thread Raw
In response to Re: Disallow cancellation of waiting for synchronous replication  (Andrey Borodin <x4mmm@yandex-team.ru>)
Responses Re: Disallow cancellation of waiting for synchronous replication  (Maksim Milyutin <milyutinma@gmail.com>)
List pgsql-hackers
Hi,

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.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Unicode escapes with any backend encoding
Next
From: Tom Lane
Date:
Subject: Re: aggregate crash