On Fri, Sep 24, 2010 at 7:47 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On Fri, 2010-09-24 at 14:12 +0300, Heikki Linnakangas wrote: >> What I'm saying is that in a two standby situation, if >> you're willing to continue operation as usual in the master even if >> the standby is down, you're not doing synchronous replication. > > Oracle and I disagree with you on that point, but I am more interested > in behaviour than semantics.
I *think* he meant s/two standby/two server/. That's taken from the 2 references: *the* master *the* slave. In that case, if the master is committing w/ no slave connected, it *isn't* repliation, synchronous or not. Usefull, likely, but replication, not at that PIT. > If you have two standbys and one is down, please explain how data loss > has occurred. Right, of course. But thinking he meant 2 servers (1 standby) not 3 servers (2 standby). But even with only 2 server, if it's down and the master is up, there isn't data loss. There's *potential* for dataloss. > But you still need to decide how you will act. I choose pragmatism in > that case. > > Others have voiced that they would like the database to shutdown or have > all sessions hang. I personally doubt their employers would feel the > same way. Arguing technical correctness would seem unlikely to allow a > DBA to keep his job if they stood and watched the app become > unavailable. Again, it all depends on the business. Synchronous replication can give you two things: 1) High Availability (Just answer my queries, dammit!) 2) High Durability (Don't give me an answer unless your damn well sure it's the right one) and its goal is to do that in the face of "catastrophic failure" (for some level of catastrophic). It's the trade of between: 1) The cost of delaying/refusing transactions being greater than the potential cost of a lost transaction 2) The cost of lost transaction being greater than the cost of delaying/refusing transactions So there are people who want to use PostgreSQL in a situation where they'ld much rather not "say" they have done something unless they are sure it's safely written in 2 different systems, in 2 different locations (and yes, the distance between those two locations will be a trade off wrt performance, and the business will need to decide on their risk levels). I understand it's optimal, desireable, or even praactical for the vast majority of cases. I don't want it to be impossible, or, if it's decide that it will be impossible, hopefully not just because you decided nobody ever needs it, but that its not feasible because of code/implimentation complexitites ;-) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
