On 02.03.2011 17:07, Robert Haas wrote:
> 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.
To achieve the effect Fujii is looking for, we would have to silently
drop the connection. That would correctly leave the client not knowing
whether the transaction committed or not.
> 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.
Yeah, I guess that would work too, if the client knows to watch out for
those warnings.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com