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: Fri, 13 May 2022 17:39:12 +0530
Message-ID: 
 <CALj2ACXKBZ-NbDMR4oE0XcS4RxuEd8BNrD2jG0gbC92bSqrV0w@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/CALj2ACXKBZ-NbDMR4oE0XcS4RxuEd8BNrD2jG0gbC92bSqrV0w%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.

Agree.

> When the network is partitioned and somewhere standby is promoted you def=
initely want infinite wait for cancels.

When standby is promoted, no point the old primary waiting forever for
ack assuming we are going to discard it.

> Yet once upon a time you want to shutdown postgres without coredump - thu=
s proc die needs to be processed.

I think users can still have the flexibility to set the right amounts
of time to process cancel and proc die interrupts.

IMHO, the GUC can still have 0, -1 and value > 0 in milliseconds, let
the users decide on what they want. Do you see any problems with this?

Thoughts?

Regards,
Bharath Rupireddy.