Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Subject: Re: An attempt to avoid
 locally-committed-but-not-replicated-to-standby-transactions in synchronous
 replication
From: Andrey Borodin <x4mmm@yandex-team.ru>
In-Reply-To: 
 <CALj2ACU=nzEb_dEfoLqez5CLcwvx1GhkdfYRNX+A4NDRbjYdBg@mail.gmail.com>
Date: Mon, 25 Jul 2022 15:50:25 +0500
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-Transfer-Encoding: quoted-printable
Message-Id: <4F070B19-51EC-4A05-A111-6001A961F991@yandex-team.ru>
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>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/4F070B19-51EC-4A05-A111-6001A961F991%40yandex-team.ru>
Precedence: bulk


> 25 =D0=B8=D1=8E=D0=BB=D1=8F 2022 =D0=B3., =D0=B2 14:29, Bharath =
Rupireddy <bharath.rupireddyforpostgres@gmail.com> =D0=BD=D0=B0=D0=BF=D0=B8=
=D1=81=D0=B0=D0=BB(=D0=B0):
>=20
> 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 =
behaviour. But I think that having no GUC here is fine too. If we do not =
allow cancelation of unreplicated backends, of course.


>>=20
>> And yes, we need additional complexity - but in some other place. =
Transaction can also be locally committed in presence of a server crash. =
But this another difficult problem. Crashed server must not allow data =
queries until LSN of timeline end is successfully replicated to =
synchronous_standby_names.
>=20
> Hm, that needs to be done anyways. How about doing as proposed
> initially upthread [1]? Also, quoting the idea here [2].
>=20
> Thoughts?
>=20
> [1] =
https://www.postgresql.org/message-id/CALj2ACUrOB59QaE6=3DjF2cFAyv1MR7fzD8=
tr4YM5+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.

Thanks!

[0] https://commitfest.postgresql.org/34/2402/