On Wed, Mar 2, 2011 at 9:30 AM, Fujii Masao <masao.fu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
