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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
