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>
In-Reply-To: <11FF616C-C78C-41AA-A823-E3D4E745ACE5@yandex-team.ru>
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Date: Mon, 25 Jul 2022 14:59:02 +0530
Message-ID: 
 <CALj2ACU=nzEb_dEfoLqez5CLcwvx1GhkdfYRNX+A4NDRbjYdBg@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/CALj2ACU%3DnzEb_dEfoLqez5CLcwvx1GhkdfYRNX%2BA4NDRbjYdBg%40mail.gmail.com>
Precedence: bulk

On Tue, May 10, 2022 at 5:55 PM Andrey Borodin <x4mmm@yandex-team.ru> wrote=
:
>
> > 10 =D0=BC=D0=B0=D1=8F 2022 =D0=B3., =D0=B2 12:59, Bharath Rupireddy <bh=
arath.rupireddyforpostgres@gmail.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=
=D0=BB(=D0=B0):
> >
> > If okay, I can make the GUC behave this way - value 0 existing
> > behaviour i.e. no wait for sync repl ack, just process query cancels
> > and proc die interrupts immediately; value -1 wait unboundedly for the
> > ack; value > 0 wait for specified milliseconds for the ack.
> +1 if we make -1 and 0 only valid values.
>
> > query cancels or proc die interrupts
>
> Please note, that typical HA tool would need to handle query cancels and =
proc die interrupts differently.

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.

However, it's good to see what other hackers think about this.

> When the network is partitioned and somewhere standby is promoted you def=
initely want infinite wait for cancels. Yet once upon a time you want to sh=
utdown postgres without coredump - thus proc die needs to be processed.

Agree.

On Mon, May 9, 2022 at 4:39 PM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>
> > On 26 Apr 2022, at 11:26, Laurenz Albe <laurenz.albe@cybertec.at> wrote=
:
> >
> > Is it worth adding additional complexity that is not a complete solutio=
n?
>
> Its not additional complexity. It is removing additional complexity that =
made sync rep interruptible. (But I'm surely talking not about GUCs like sy=
nchronous_replication_naptime_before_cancel - wait of sync rep must be inde=
finite until synchrous_commit\synchronous_standby_names are satisfied )
>
> And yes, we need additional complexity - but in some other place. Transac=
tion 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_name=
s.

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=3DjF2cFAyv1MR7f=
zD8tr4YM5+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.

Regards,
Bharath Rupireddy.