On Fri, Feb 25, 2011 at 3:44 PM, Josh Berkus <j...@agliodbs.com> wrote: > >> Right now, as it stands, the syncrep patch will be happy as soon as >> the data has been fsynced to either B or A-prime; I don't think we can >> guarantee at any point that A-prime can become the leader, and feed B. > > Yeah, I think that's something we said months ago is going to be a 9.2 > feature, no sooner.
Ah, okay, I had missed that discussion, I also did not know it got so specific as to address this case (are you sure?) rather than something more general, say quorum or N-safe durability. >> 2. The unprivileged user can disable syncrep, in any situation. This >> flexibility is *great*, but you don't really want people to do it when >> one is performing the switchover. Rather, in a magical world we'd hope >> that disabling syncrep would just result in not having to >> synchronously commit to B (but, in this case, still synchronously >> commit to A-prime) >> >> In other words, to my mind, you can use syncrep as-is to provide >> 2-safe durability xor a scheduled switchover: as soon as someone wants >> both, I think they'll have some trouble. I do want both, though. > > Hmmm, I don't follow this. The user can only disable syncrep for their > own transactions. If they don't care about the persistence of their > transaction post-failover, why should the DBA care? The user may have their own level of durability guarantee they want to attain (that's why machine "B" is syncrepped in my example), but when doing the switchover I think an override to enable a smooth handoff (meaning: everything syncrepped) would be best. What I want to avoid is an ack from "COMMIT" from the primary (machine "A"), and then, post switchover, the data isn't there on machine A-Prime (or "B", provided it was able to follow successfully at all, as in the current case it might get ahead of A-prime in the WAL). -- fdr -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers