Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 40982B5DC13 for ; Mon, 1 Aug 2011 16:52:54 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 06497-04 for ; Mon, 1 Aug 2011 19:52:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mail.postgresql.org (Postfix) with ESMTP id 95146B5DC08 for ; Mon, 1 Aug 2011 16:52:47 -0300 (ADT) Received: from [192.168.1.7] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0LiCNn-1R9LH310eB-00nRrb; Mon, 01 Aug 2011 21:52:46 +0200 Message-ID: <4E37040D.8000000@2ndQuadrant.com> Date: Mon, 01 Aug 2011 15:52:45 -0400 From: Greg Smith User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: synchronous_commit off References: <001201cc504f$11f32e50$35d98af0$@devshock.com> In-Reply-To: <001201cc504f$11f32e50$35d98af0$@devshock.com> Content-Type: multipart/alternative; boundary="------------040706040201010104060302" X-Provags-ID: V02:K0:ZnJYNRjsMD8oSEdGO9Chn/YBj0NMpnnd9Q8lV4065lG YApO9+x5vMBk1+TFKIy6gx3qZMETBhE6ZcbTDBltkxNET0llxK 04sPXueulxpL6na5oH8u5T295dlw09jI5EEJ64oXdzJBx7rZGZ nHsb29BhYpyKil9wYnIFzDZClq6nDQbbYOXD0gb7Uj4794b7Ne D+f2wbd/6KNOd8itGxP8md88J//1lOH4VRcqo7573M= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.899 tagged_above=-10 required=5 tests=BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201108/10 X-Sequence-Number: 44457 This is a multi-part message in MIME format. --------------040706040201010104060302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us --------------040706040201010104060302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us

--------------040706040201010104060302--