On Sun, Jun 16, 2013 at 5:10 PM, Simon Riggs
<simon@2ndquadrant.com> wrote:
So I strongly object to calling this patch anything to do with
"failback safe". You simply don't have enough data to make such a bold
claim. (Which is why we call it synchronous replication and not "zero
data loss", for example).
But that's not the whole story. I can see some utility in a patch that
makes all WAL transfer synchronous, rather than just commits. Some
name like synchronous_transfer might be appropriate. e.g.
synchronous_transfer = all | commit (default).
I agree with you about the fact that,
Now a days the need of fresh backup in crash recovery seems to be a major problem.
we might need to change the name of patch if there other problems too with crash recovery.
The idea of another slew of parameters that are very similar to
synchronous replication but yet somehow different seems weird. I can't
see a reason why we'd want a second lot of parameters. Why not just
use the existing ones for sync rep? (I'm surprised the Parameter
Police haven't visited you in the night...) Sure, we might want to
expand the design for how we specify multi-node sync rep, but that is
a different patch.
The different set of parameters are needed to differentiate between fail-safe standby and synchronous standby, the fail-safe standby and standby in synchronous replication can be two different servers.
I'm worried to see that adding this feature and yet turning it off
causes a measureable drop in performance. I don't think we want that
at all. That clearly needs more work and thought.
I also think your performance results are somewhat bogus. Fast
transaction workloads were already mostly commit waits - measurements
of what happens to large loads, index builds etc would likely reveal
something quite different.
I will test the other scenarios and post the results.
--