On Wed, Mar 2, 2011 at 9:30 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> What I'm thinking is: when the waiting backends are released because
> of the timeout while the fast shutdown is being done in the master,
> those backends should not return the success indication to the client.
> Of course, in that case, WAL has already been flushed in the master,
> but I think that those backends should exit with FATAL error before
> returning the success. This is for avoiding breaking the synchronous
> replication rule, i.e., all the transaction which the client knows as
> committed must be committed in the synchronous standby after failover.
That seems like an extremely bad idea. Now any client that assumes
that FATAL means his transaction didn't commit is broken. Clients
should be entitled to assume that a successful COMMIT means the
transaction committed (with whatever the operative durability
guarantee is) and that an error means it rolled back. If the
connection is closed before either one of those things happens, the
client can't assume anything.
It might be reasonable to COMMIT but also issue a warning message, or
to just close the connection without telling the client what happened,
but sending an error seems poor.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
