public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bharath Rupireddy <[email protected]>
To: Andrey Borodin <[email protected]>
To: PostgreSQL Hackers <[email protected]>
To: Dilip Kumar <[email protected]>
To: Laurenz Albe <[email protected]>
To: SATYANARAYANA NARLAPURAM <[email protected]>
Subject: Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication
Date: Thu, 4 Aug 2022 14:01:40 +0530
Message-ID: <CALj2ACUiyE1ui4Daqw1cw-tLTSqkiB1bYZ6rWb5BE70-C65Cog@mail.gmail.com> (raw)
In-Reply-To: <CALj2ACV1WBqtdwMXV7TCfPiAVdHNF=8n1tiCWpv0yS-mbqeWZg@mail.gmail.com>
References: <CALj2ACUrOB59QaE6=jF2cFAyv1MR7fzD8tr4YM5+OwEYG1SNzA@mail.gmail.com>
<[email protected]>
<CALj2ACWoB3k0kfjA7JxJgskVGGeE3jWzmGRPjP9QTRSCgSjhOg@mail.gmail.com>
<[email protected]>
<CAFiTN-tzW+pFXGh-NqZCJmBGPsd2EHtvYvSxvsZTH7=cWsdPMw@mail.gmail.com>
<CALj2ACVuj=Fo55NdWJy=fwweC-+pi7eQPRN3Kij3PQQcWFtYxQ@mail.gmail.com>
<[email protected]>
<CALj2ACU=nzEb_dEfoLqez5CLcwvx1GhkdfYRNX+A4NDRbjYdBg@mail.gmail.com>
<[email protected]>
<CALj2ACV1WBqtdwMXV7TCfPiAVdHNF=8n1tiCWpv0yS-mbqeWZg@mail.gmail.com>
On Thu, Aug 4, 2022 at 1:42 PM Bharath Rupireddy
<[email protected]> wrote:
>
> On Mon, Jul 25, 2022 at 4:20 PM Andrey Borodin <[email protected]> wrote:
> >
> > > 25 июля 2022 г., в 14:29, Bharath Rupireddy <[email protected]> написал(а):
> > >
> > > 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.
> >
> > >>
> > >> 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.
> > >
> > > 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/[email protected]...
> > > [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.
Continuing on the above thought (I inadvertently clicked the send
button previously): A simple approach would be to check for quorum in
PostgresMain() before entering the query loop for (;;) for
non-walsender cases. A disadvantage of this would be that all the
backends will be waiting here in the worst case if it takes time for
achieving the sync quorum after restart - roughly we can do the
following in PostgresMain(), of course we need locking mechanism so
that all the backends whoever reaches here will wait for the same lsn:
if (sync_replicaion_defined == true &&
shmem->wait_for_sync_repl_upon_restart == true)
{
SyncRepWaitForLSN(pg_current_wal_flush_lsn(), false);
shmem->wait_for_sync_repl_upon_restart = false;
}
Thoughts?
--
Bharath Rupireddy
RDS Open Source Databases: https://aws.amazon.com/rds/postgresql/
view thread (37+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication
In-Reply-To: <CALj2ACUiyE1ui4Daqw1cw-tLTSqkiB1bYZ6rWb5BE70-C65Cog@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox