MIME-Version: 1.0
References: 
 <CALj2ACUrOB59QaE6=jF2cFAyv1MR7fzD8tr4YM5+OwEYG1SNzA@mail.gmail.com>
 <9290b55b6ae2b04e002ca9dadadd1cca09461482.camel@cybertec.at>
 <CALj2ACWoB3k0kfjA7JxJgskVGGeE3jWzmGRPjP9QTRSCgSjhOg@mail.gmail.com>
 <763B5AF0-1C9E-4796-9639-F969A2E66189@yandex-team.ru>
 <CAFiTN-tzW+pFXGh-NqZCJmBGPsd2EHtvYvSxvsZTH7=cWsdPMw@mail.gmail.com>
 <CALj2ACVuj=Fo55NdWJy=fwweC-+pi7eQPRN3Kij3PQQcWFtYxQ@mail.gmail.com>
 <11FF616C-C78C-41AA-A823-E3D4E745ACE5@yandex-team.ru>
 <CALj2ACU=nzEb_dEfoLqez5CLcwvx1GhkdfYRNX+A4NDRbjYdBg@mail.gmail.com>
 <4F070B19-51EC-4A05-A111-6001A961F991@yandex-team.ru>
In-Reply-To: <4F070B19-51EC-4A05-A111-6001A961F991@yandex-team.ru>
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Date: Thu, 4 Aug 2022 13:42:02 +0530
Message-ID: 
 <CALj2ACV1WBqtdwMXV7TCfPiAVdHNF=8n1tiCWpv0yS-mbqeWZg@mail.gmail.com>
Subject: Re: An attempt to avoid
 locally-committed-but-not-replicated-to-standby-transactions
 in synchronous replication
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Dilip Kumar <dilipbalaut@gmail.com>,
 Laurenz Albe <laurenz.albe@cybertec.at>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
	SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CALj2ACV1WBqtdwMXV7TCfPiAVdHNF%3D8n1tiCWpv0yS-mbqeWZg%40mail.gmail.com>
Precedence: bulk

On Mon, Jul 25, 2022 at 4:20 PM Andrey Borodin <x4mmm@yandex-team.ru> wrote=
:
>
> > 25 =D0=B8=D1=8E=D0=BB=D1=8F 2022 =D0=B3., =D0=B2 14:29, Bharath Rupired=
dy <bharath.rupireddyforpostgres@gmail.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0=D0=BB(=D0=B0):
> >
> > Hm, after thinking for a while, I tend to agree with the above
> > approach - meaning, query cancel interrupt processing can completely
> > be disabled in SyncRepWaitForLSN() and process proc die interrupt
> > immediately, this approach requires no GUC as opposed to the proposed
> > v1 patch upthread.
> GUC was proposed here[0] to maintain compatibility with previous behaviou=
r. But I think that having no GUC here is fine too. If we do not allow canc=
elation of unreplicated backends, of course.
>
> >>
> >> And yes, we need additional complexity - but in some other place. Tran=
saction can also be locally committed in presence of a server crash. But th=
is another difficult problem. Crashed server must not allow data queries un=
til LSN of timeline end is successfully replicated to synchronous_standby_n=
ames.
> >
> > Hm, that needs to be done anyways. How about doing as proposed
> > initially upthread [1]? Also, quoting the idea here [2].
> >
> > Thoughts?
> >
> > [1] https://www.postgresql.org/message-id/CALj2ACUrOB59QaE6=3DjF2cFAyv1=
MR7fzD8tr4YM5+OwEYG1SNzA@mail.gmail.com
> > [2] 2) Wait for sync standbys to catch up upon restart after the crash =
or
> > in the next txn after the old locally committed txn was canceled. One
> > way to achieve this is to let the backend, that's making the first
> > connection, wait for sync standbys to catch up in ClientAuthentication
> > right after successful authentication. However, I'm not sure this is
> > the best way to do it at this point.
>
>
> I think ideally startup process should not allow read only connections in=
 CheckRecoveryConsistency() until WAL is not replicated to quorum al least =
up until new timeline LSN.

We can't do it in CheckRecoveryConsistency() unless I'm missing
something. Because, the walsenders (required for sending the remaining
WAL to sync standbys to achieve quorum) can only be started after the
server reaches a consistent state, after all walsenders are
specialized backends.


--=20
Bharath Rupireddy
RDS Open Source Databases: https://aws.amazon.com/rds/postgresql/