Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 52DDF1337B81 for ; Fri, 18 Mar 2011 13:28:17 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 57489-07 for ; Fri, 18 Mar 2011 16:28:07 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from gw.wicourts.gov (gwmta.wicourts.gov [165.219.244.99]) by mail.postgresql.org (Postfix) with ESMTP id 97B721337B83 for ; Fri, 18 Mar 2011 13:28:06 -0300 (ADT) Received: from Courts-MTA by gw.wicourts.gov with Novell_GroupWise; Fri, 18 Mar 2011 11:28:05 -0500 Message-Id: <4D8341BD020000250003BAB2@gw.wicourts.gov> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 18 Mar 2011 11:27:57 -0500 From: "Kevin Grittner" To: "Heikki Linnakangas" Cc: "Simon Riggs" , "Markus Wanner" , "Alvaro Herrera" , "Andrew Dunstan" , "MARK CALLAGHAN" , "Aidan Van Dyk" , "pgsql-hackers" Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. References: <4D741441.2090704@dunslane.net> <1299454125.1696.6138.camel@ebony> <4D74896C.5030402@enterprisedb.com> <4D74DDFA.70800@dunslane.net> <4D74E584.7080409@enterprisedb.com> <4D74E9FA.7070202@dunslane.net> <4D74F3AE.9000802@dunslane.net> <4D74FDEC.5040406@enterprisedb.com> <4D74FF15.1070804@dunslane.net> <1299513979-sup-1987@alvh.no-ip.org> <4D832571.5030808@bluegap.ch> <1300457958.18619.13780.camel@ebony> <4D832B4D020000250003BA98@gw.wicourts.gov> <4D837EA2.2070205@enterprisedb.com> In-Reply-To: <4D837EA2.2070205@enterprisedb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=2.409 tagged_above=-5 required=5 tests=BAYES_00=-1.9, FS_REPLICA=3.599, SARE_SPEC_REPLICA=0.72, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: ** X-Archive-Number: 201103/1147 X-Sequence-Number: 184397 > On 18.03.2011 16:52, Kevin Grittner wrote: >> Simon Riggs wrote: >> >>> In PostgreSQL other users cannot observe the commit until an >>> acknowledgement has been received. >> >> Really? I hadn't picked up on that. That makes for a lot of >> complication on crash-and-recovery of a master, but if we can >> pull it off, that's really cool. Markus Wanner wrote: > What complication do you have in mind here? Basically, what Heikki addresses. It has to be committed after crash and recovery, and deal with replicas which may or may not have been notified and may or may not have applied the transaction. Heikki Linnakangas wrote: > To be clear: other users cannot observe the commit until standby > acknowledges it - unless the master crashes while waiting for the > acknowledgment. If that happens, the commit will be visible to > everyone after recovery. Right. If other transactions cannot see the transaction before the COMMIT returns, I was kinda assuming that this was the behavior, because otherwise one or more replicas could be ahead of the master after recovery, which would be horribly broken. I agree that the behavior which you describe is much better than allowing other transactions to see the work of the pending COMMIT. In fact, on further reflection, allowing other transactions to see work before the committing transaction returns could lead to broken behavior if that viewing transaction took some action based on the that, the master crashed, recovery was done using a standby, and that standby hadn't persisted the transaction. So this behavior is necessary for good behavior. Even though that "perfect storm" of events might be fairly rare, the difference in the level of confidence in correctness is significant, and certainly something to brag about. -Kevin