On 02.03.2011 17:07, Robert Haas wrote:
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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
