> 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. > 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? -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers