| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Disallow quorum uncommitted (with synchronous standbys) txns in logical replication subscribers |
| Date: | 2022-01-07 20:22:36 |
| Message-ID: | 20220107202236.gi4ux3ozzmngcpj2@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2022-01-06 23:24:40 -0800, Jeff Davis wrote:
> 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 don't see how it can *not* cause a major performance / latency
gotcha. You're deliberately delaying replication after all?
Synchronous replication doesn't guarantee *anything* about the ability for to
fail over for other replicas. Nor would it after what's proposed here -
another sync replica would still not be guaranteed to be able to follow the
newly promoted primary.
To me this just sounds like trying to shoehorn something into syncrep that
it's not made for.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2022-01-07 20:24:20 | Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations |
| Previous Message | Bossart, Nathan | 2022-01-07 20:20:31 | Re: Worth using personality(ADDR_NO_RANDOMIZE) for EXEC_BACKEND on linux? |