Re: Disallow quorum uncommitted (with synchronous standbys) txns in logical replication subscribers - Mailing list pgsql-hackers

From SATYANARAYANA NARLAPURAM
Subject Re: Disallow quorum uncommitted (with synchronous standbys) txns in logical replication subscribers
Date
Msg-id CAHg+QDc9sDR3mHBWpu6zyyUB75N2CXvA1Ntv-703yv61UHXrbg@mail.gmail.com
Whole thread Raw
In response to Re: Disallow quorum uncommitted (with synchronous standbys) txns in logical replication subscribers  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Disallow quorum uncommitted (with synchronous standbys) txns in logical replication subscribers
List pgsql-hackers


On Thu, Jan 6, 2022 at 11:24 PM Jeff Davis <pgsql@j-davis.com> wrote:
On Wed, 2022-01-05 at 23:59 -0800, SATYANARAYANA NARLAPURAM wrote:
> I would like to propose a GUC send_Wal_after_quorum_committed which
> when set to ON, walsenders corresponds to async standbys and logical
> replication workers wait until the LSN is quorum committed on the
> primary before sending it to the standby. This not only simplifies
> the post failover steps but avoids unnecessary downtime for the async
> replicas. Thoughts?

Do we need a GUC? Or should we just always require that sync rep is
satisfied before sending to async replicas?
 
I proposed a GUC to not introduce a behavior change by default. I have no strong opinion on having a GUC or making the proposed behavior default, would love to get others' perspectives as well.
 

It feels like the sync quorum should always be ahead of the async
replicas. Unless I'm missing a use case, or there is some kind of
performance gotcha.
 
I couldn't think of a case that can cause serious performance issues but will run some experiments on this and post the numbers.

 

Regards,
        Jeff Davis


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: preserve timestamps when installing headers
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Disallow quorum uncommitted (with synchronous standbys) txns in logical replication subscribers