From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Allow async standbys wait for sync replication (was: Disallow quorum uncommitted (with synchronous standbys) txns in logical replication subscribers) |
Date: | 2022-02-28 18:57:32 |
Message-ID: | 20220228185732.GB944837@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Feb 28, 2022 at 06:45:51PM +0530, Bharath Rupireddy wrote:
> On Sat, Feb 26, 2022 at 9:37 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>> For
>> this feature, I think we always need to consider what the primary considers
>> synchronously replicated. My suggested approach doesn't change that. I'm
>> saying that instead of spinning in a loop waiting for the WAL to be
>> synchronously replicated, we just immediately send WAL up to the LSN that
>> is presently known to be synchronously replicated.
>
> As I said above, v1 patch does that i.e. async standbys wait until the
> sync standbys update their flush LSN.
>
> Flush LSN is this - flushLSN = walsndctl->lsn[SYNC_REP_WAIT_FLUSH];
> which gets updated in SyncRepReleaseWaiters.
>
> Async standbys with their SendRqstPtr will wait in XLogSendPhysical or
> XLogSendLogical until SendRqstPtr <= flushLSN.
My feedback is specifically about this behavior. I don't think we should
spin in XLogSend*() waiting for an LSN to be synchronously replicated. I
think we should just choose the SendRqstPtr based on what is currently
synchronously replicated.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Champion | 2022-02-28 18:58:00 | Re: [PATCH] Expose port->authn_id to extensions and triggers |
Previous Message | Nathan Bossart | 2022-02-28 18:51:21 | Re: parse/analyze API refactoring |