On Tue, Jan 3, 2012 at 9:22 PM, Robert Haas <robertmh...@gmail.com> wrote:
> It seems to me that if you are happy with #2, you don't really need to > enable sync rep in the first place. > > At any rate, even without multiple component failures, this > configuration makes it pretty easy to lose durability (which is the > only point of having sync rep in the first place). Suppose the NIC > card on the master is the failing component. If it happens to drop > the TCP connection to the clients just before it drops the connection > to the standby, the standby will have all the transactions, and you > can fail over just fine. If it happens to drop the TCP connection to > the just before it drops the connection to the clients, the standby > will not have all the transactions, and failover will lose some > transactions - and presumably you enabled this feature in the first > place precisely to prevent that sort of occurrence. > > I do think that it might be useful to have this if there's a > configurable timeout involved - that way, people could say, well, I'm > OK with maybe losing transactions if the standby has been gone for X > seconds. But if the only possible behavior is equivalent to a > zero-second timeout I don't think it's too useful. It's basically > just going to lead people to believe that their data is more secure > than it really is, which IMHO is not helpful. So, I'm a big fan of syncrep guaranteeing it's guarantees. To me, that's the whole point. Having it "fall out of sync rep" at any point *automatically* seems to be exactly counter to the point of sync rep. That said, I'm also a big fan of monitoring everything as well as I could... I'ld love a "hook" script that was run if sync-rep state ever changed (heck, I'ld even like it if it just choose a new sync standby). Even better, is there a way we could start injecting "notify" events into the cluster on these types of changes? Especially now that notify events can take payloads, it means I don't have to keep constantly polling the database to see if it things its connected, etc. a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
