On Thu, May 27, 2010 at 9:09 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Thu, May 27, 2010 at 9:48 PM, Robert Haas <robertmh...@gmail.com> wrote: >> There could still be additional transactions that the original master >> has committed locally but were not acked to the client. I guess you'd >> just work around that by taking a new base backup from the new master. > > Right. > > Unfortunately the transaction aborted for a client might have already > been committed in the standby. In this case, we might need to eliminate > the mismatch of transaction status between a client and new master > after failover. > > BTW, the similar situation might happen even when only one server is > running. If the server goes down before returning a "success" to a > client after flushing the commit record, the mismatch would happen > after restart of the server.
True. But that's a slightly different case. Clients could fail to receive commit ACKs for a variety of reasons, like losing network connectivity momentarily. They had better be prepared for that no matter whether replication is in use or not. The new issue that replication adds is that you've got to make sure that the two (or n) nodes don't disagree with each other. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
