On Thu, May 27, 2010 at 9:09 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Thu, May 27, 2010 at 9:48 PM, Robert Haas <robertmhaas@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
