Shaun, > Too many mental gymnastics. I get that async is "faster" than sync, but > the inconsistent transactional state makes it *look* slower. If a > customer makes an order, but just happens to check that order state on > the secondary before it can catch up, that's a net loss. Like I said, > that's fine for our DR system, or a reporting mirror, or any one of > several use-case scenarios, but it's not good enough for a failover when > better alternatives exist. In this case, better alternatives are > anything that can guarantee transaction durability: DRBD / PG sync.
Per your exchange with Heikki, that's not actually how SyncRep works in 9.1. So it's not giving you what you want anyway. This is why we felt that the "sync rep if you can" mode was useless and didn't accept it into 9.1. The *only* difference between sync rep and async rep is whether or not the master waits for ack that the standby has written to log. I think one of the new modes in 9.2 forces synch-to-DB before ack. No? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
