On Sun, 2008-12-14 at 21:41 -0500, Robert Haas wrote:
> > If this is right, #2, #3, #4, and #6 feel similar except
> > that they're protecting against failures of different (but
> > still all incomplete) subsets of the hardware on the slave, right?
>
> Right. Actually, the biggest difference with #6 has nothing to do
> with protecting against failures. It has rather to do with the ease
> of writing applications in the context of hot standby. You can close
> your connection, open a connection to a different server, and know
> that your transactions will be reflected there. On the other hand,
> I'd be surprised if it didn't come with a substantial performance
> penalty, so it may not be too practical in real life even if it sounds
> good on paper.
>
> #1 , #3, and #5 don't feel that useful to me.
Yes, looks that way for me also.
Good analysis Ron. I agree with Robert that #6 is there for other
reasons.
#2 corresponds to DRBD algorithm B
#4 corresponds to DRBD algorithm C
Fujii-san, please can we incorporate those two options, rather than just
one choice "synchronous_replication = on". They look like two commonly
requested options.
#6 is an additional synchronization step in Hot Standby. I would say
that people won't want that when they see how it performs (they probably
won't want #4 either for that same reason, but that is for robustness).
Also, I would point out that the class of synch_rep is selected by the
user on the primary and can vary from transaction to transaction. That
is a very good thing, as far as I am concerned. We would need to enforce
#6 for all transactions (if we implemented synchronisation in this way).
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
