On Fri, Feb 25, 2011 at 4:36 PM, Josh Berkus <j...@agliodbs.com> wrote: > Daniel, > >> 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. > > The way we address that case is through n-safe durability.
How is this exposed? The simple "count the number of fsyncs()" approach is not quite good enough (one has no control to make sure one or more nodes are definitely up-to-date) unless one wants to just make it go to *all* syncrep standys for a while. That seems like overkill; so I imagine something else is in the thoughts. I'll search the archives... >> 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). > > Yeah, when I think about your use case, I can understand why it's an > issue. It would be nice to have a superuser setting (or similar) which > could override user preferances and make all transactions synchrep > temporarily. I'm not sure that's going to be reasonable to do for 9.1 > though. Agreed; I'd be happy to take any syncrep functionality, although it wouldn't compose well as-is, I wanted to raise this so that we didn't make any configuration decisions that got in the way of making composition possible later. Again, I haven't thought ahead yet, partially because I thought there may be some existing thoughts in play to consider. With that, I will try to give syncrep a more structured review Real Soon, although the late date of this is leaving me queasy as to the odds of git-commit. -- fdr -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers