Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 10D35B5E0B0 for ; Mon, 1 Aug 2011 17:20:00 -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 59197-05 for ; Mon, 1 Aug 2011 20:19:53 +0000 (UTC) X-Greylist: delayed 05:39:43.948093 by SQLgrey-1.7.6 Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.213.174]) by mail.postgresql.org (Postfix) with ESMTP id 0EFC3B5F42B for ; Mon, 1 Aug 2011 17:05:41 -0300 (ADT) Received: by yxi11 with SMTP id 11so3374691yxi.19 for ; Mon, 01 Aug 2011 13:05:41 -0700 (PDT) Received: by 10.236.173.102 with SMTP id u66mr3520858yhl.69.1312229140447; Mon, 01 Aug 2011 13:05:40 -0700 (PDT) Received: from AnibalVAIO ([200.85.32.68]) by mx.google.com with ESMTPS id p50sm2483505yhj.28.2011.08.01.13.05.37 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Aug 2011 13:05:38 -0700 (PDT) From: "Anibal David Acosta" To: "'Greg Smith'" , References: <001201cc504f$11f32e50$35d98af0$@devshock.com> <4E37040D.8000000@2ndQuadrant.com> In-Reply-To: <4E37040D.8000000@2ndQuadrant.com> Subject: Re: synchronous_commit off Date: Mon, 1 Aug 2011 16:05:39 -0400 Message-ID: <007101cc5086$64966780$2dc33680$@devshock.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0072_01CC5064.DD84C780" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIoR6YgVoRG0Gdrw5Qp+7eVvPx2eAGl0RKOlENNeHA= Content-Language: es-py 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 X-Spam-Level: X-Archive-Number: 201108/11 X-Sequence-Number: 44458 This is a multipart message in MIME format. ------=_NextPart_000_0072_01CC5064.DD84C780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit the application doesn't manage money or something really really critical, so I can live with the "in case of crash" that is not a normal behavior J Thanks. De: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-owner@postgresql.org] En nombre de Greg Smith Enviado el: lunes, 01 de agosto de 2011 03:53 p.m. Para: pgsql-performance@postgresql.org Asunto: Re: [PERFORM] synchronous_commit off 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 ------=_NextPart_000_0072_01CC5064.DD84C780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

the application doesn't = manage money or something really really critical, so I can live with the = “in case of crash” that is not a normal behavior = J

 

 

Thanks.

 

 

 

De: pgsql-performance-owner@postgresql.org = [mailto:pgsql-performance-owner@postgresql.org] En nombre de Greg = Smith
Enviado el: lunes, 01 de agosto de 2011 03:53 = p.m.
Para: pgsql-performance@postgresql.org
Asunto: = Re: [PERFORM] synchronous_commit off

 

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
------=_NextPart_000_0072_01CC5064.DD84C780--