On Fri, 2022-01-07 at 12:22 -0800, Andres Freund wrote:
> I don't see how it can *not* cause a major performance / latency
> gotcha. You're deliberately delaying replication after all?
Are there use cases where someone wants sync rep, and also wants their
read replicas to get ahead of the sync rep quorum?
If the use case doesn't exist, it doesn't make sense to talk about how
well it performs.
> another sync replica would still not be guaranteed to be able to
> follow the
> newly promoted primary.
If you only promote the furthest-ahead sync replica (which is what you
should be doing if you have quorum commit), why wouldn't that work?
> To me this just sounds like trying to shoehorn something into syncrep
> that
> it's not made for.
What *is* sync rep made for?
The only justification in the docs is around durability:
"[sync rep] extends that standard level of durability offered by a
transaction commit... [sync rep] can provide a much higher level of
durability..."
If we take that at face value, then it seems logical to say that async
read replicas should not get ahead of sync replicas.
Regards,
Jeff Davis
