Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id B1D55B5DBE2 for ; Mon, 1 Aug 2011 20:49:27 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 38425-02 for ; Mon, 1 Aug 2011 23:49:21 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from www.postnewspapers.com.au (www.postnewspapers.com.au [96.126.97.249]) by mail.postgresql.org (Postfix) with ESMTP id 4292FB5DBCE for ; Mon, 1 Aug 2011 20:49:21 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by www.postnewspapers.com.au (Postfix) with ESMTP id 94C9810D; Mon, 1 Aug 2011 19:49:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at postnewspapers.com.au.com Received: from www.postnewspapers.com.au ([127.0.0.1]) by localhost (www.postnewspapers.com.au [127.0.0.1]) (amavisd-new, port 10024) with LMTP id O3XHBReDiFA3; Mon, 1 Aug 2011 19:49:19 -0400 (EDT) Received: from mail.postnewspapers.com.au (office1.postnewspapers.com.au [150.101.171.128]) by www.postnewspapers.com.au (Postfix) with ESMTP id 287CB47; Mon, 1 Aug 2011 19:49:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.postnewspapers.com.au (Postfix) with ESMTP id 2B191AE934; Tue, 2 Aug 2011 07:49:18 +0800 (WST) X-Amavis-Modified: Mail body modified (using disclaimer) - mail.postnewspapers.com.au X-Virus-Scanned: Debian amavisd-new at postnewspapers.com.au Received: from mail.postnewspapers.com.au ([127.0.0.1]) by localhost (mail.postnewspapers.com.au [127.0.0.1]) (amavisd-new, port 10024) with LMTP id a18Ujy3IMBuq; Tue, 2 Aug 2011 07:49:13 +0800 (WST) Received: from [10.1.1.8] (124-169-181-228.dyn.iinet.net.au [124.169.181.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Craig Ringer", Issuer "POST Certificate Authority" (verified OK)) by mail.postnewspapers.com.au (Postfix) with ESMTPSA id DFD49AE933; Tue, 2 Aug 2011 07:49:12 +0800 (WST) Message-ID: <4E373B77.8060001@postnewspapers.com.au> Date: Tue, 02 Aug 2011 07:49:11 +0800 From: Craig Ringer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Greg Smith CC: pgsql-performance@postgresql.org Subject: Re: synchronous_commit off References: <001201cc504f$11f32e50$35d98af0$@devshock.com> <4E37040D.8000000@2ndQuadrant.com> In-Reply-To: <4E37040D.8000000@2ndQuadrant.com> Content-Type: multipart/alternative; boundary="------------000208080309020100020406" X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.622 tagged_above=-10 required=5 tests=BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.723 X-Spam-Level: X-Archive-Number: 201108/13 X-Sequence-Number: 44460 This is a multi-part message in MIME format. --------------000208080309020100020406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/08/2011 3:52 AM, Greg Smith wrote: > On 08/01/2011 09:29 AM, Anibal David Acosta wrote: >> >> Can a transaction committed asynchronously report an error, duplicate >> key or something like that, causing a client with a OK transaction >> but server with a FAILED transaction. >> >> > > No. You are turning off the wait for the transaction to hit disk > before returning to the client, but all the validation checks are done > before that. The sole risk with synchronous_commit off is that a > client will get COMMIT, but the server will lose the transaction > completely--when there's a crash before it's written to disk. What about an I/O error during write, or other HW-level issues that might cause a transaction to fail to commit while others proceed fine? -- Craig Ringer POST Newspapers 276 Onslow Rd, Shenton Park Ph: 08 9381 3088 Fax: 08 9388 2258 ABN: 50 008 917 717 http://www.postnewspapers.com.au/ --------------000208080309020100020406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2/08/2011 3:52 AM, Greg Smith wrote:
On 08/01/2011 09:29 AM, Anibal David Acosta wrote:

Can a transaction committed asynchronously report an error, duplicate key or something like that, causing a client with a OK transaction but server with a FAILED transaction.



No.  You are turning off the wait for the transaction to hit disk before returning to the client, but all the validation checks are done before that.  The sole risk with synchronous_commit off is that a client will get COMMIT, but the server will lose the transaction completely--when there's a crash before it's written to disk.

What about an I/O error during write, or other HW-level issues that might cause a transaction to fail to commit while others proceed fine?

--
Craig Ringer

POST Newspapers 276 Onslow Rd, Shenton Park Ph: 08 9381 3088 Fax: 08 9388 2258 ABN: 50 008 917 717 http://www.postnewspapers.com.au/
--------------000208080309020100020406--