From aa@devshock.com Mon Aug 1 15:23:02 2011 Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 9E3C7B5DBCE for ; Mon, 1 Aug 2011 12:23:02 -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 59482-01 for ; Mon, 1 Aug 2011 15:22:56 +0000 (UTC) X-Greylist: delayed 01:45:29.266591 by SQLgrey-1.7.6 Received: from mail-gw0-f46.google.com (mail-gw0-f46.google.com [74.125.83.46]) by mail.postgresql.org (Postfix) with ESMTP id 7233EB5D800 for ; Mon, 1 Aug 2011 12:22:56 -0300 (ADT) Received: by gwaa12 with SMTP id a12so1456046gwa.19 for ; Mon, 01 Aug 2011 08:22:55 -0700 (PDT) Received: by 10.236.189.97 with SMTP id b61mr2909109yhn.482.1312205378197; Mon, 01 Aug 2011 06:29:38 -0700 (PDT) Received: from AnibalVAIO (host-5-144.a5.cmm.com.py [190.2.196.144]) by mx.google.com with ESMTPS id k8sm3678195yhm.3.2011.08.01.06.29.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Aug 2011 06:29:36 -0700 (PDT) From: "Anibal David Acosta" To: Subject: synchronous_commit off Date: Mon, 1 Aug 2011 09:29:37 -0400 Message-ID: <001201cc504f$11f32e50$35d98af0$@devshock.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01CC502D.8AE314F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxQTUmbo5y7VihvRAmBVWqPpVQYQg== 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/9 X-Sequence-Number: 44456 This is a multipart message in MIME format. ------=_NextPart_000_0013_01CC502D.8AE314F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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. Thanks ------=_NextPart_000_0013_01CC502D.8AE314F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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.

Thanks

------=_NextPart_000_0013_01CC502D.8AE314F0-- From greg@2ndQuadrant.com Mon Aug 1 19:52:54 2011 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-- From aa@devshock.com Mon Aug 1 20:20:00 2011 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-- From craig@postnewspapers.com.au Mon Aug 1 23:49:27 2011 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-- From lhofhansl@yahoo.com Wed Aug 3 00:08:17 2011 Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 3A863B5DBC6 for ; Tue, 2 Aug 2011 21:08:17 -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 52166-05 for ; Wed, 3 Aug 2011 00:08:10 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from nm12-vm1.bullet.mail.ne1.yahoo.com (nm12-vm1.bullet.mail.ne1.yahoo.com [98.138.91.41]) by mail.postgresql.org (Postfix) with SMTP id D7DDFB5DBC5 for ; Tue, 2 Aug 2011 21:08:09 -0300 (ADT) Received: from [98.138.90.53] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 03 Aug 2011 00:08:08 -0000 Received: from [98.138.89.244] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 03 Aug 2011 00:08:08 -0000 Received: from [127.0.0.1] by omp1058.mail.ne1.yahoo.com with NNFMP; 03 Aug 2011 00:08:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 927674.69799.bm@omp1058.mail.ne1.yahoo.com Received: (qmail 89739 invoked by uid 60001); 3 Aug 2011 00:08:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312330088; bh=E7y/P1/1zAHDzjUEeSGU9PydspY64q4gcxsEPx90z9g=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ICKNdPk/EpiE+1Q68hbOkeOrRJiXccff64m4PqQySK/zViv/ZKLEPWOmLF1yn18LpfXHb486pQiLbe5GAv++ENuup2xzyuO3wu9VBaEnREGR+PmQKz+FPSyK9HYZK4Ofh3tDgeAV6Qr5J3nrnTDbR2efohBeeX5+sUG1wYFbyf8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=QbdpCazCaFpDWrMiip9rqtlW44VHm8R+WuzmyBvJtD20qjF8CzHwvDYv2OHlccUMdtTj7vVcgcRrJb54yFZiY3/MIzd96IiEGttsLqHF/4/63Yw6f/pAwYSLvXRIvdCI+qGlWbRjIEhdnx9bItot6cr3Gns9GJZ5bamnkcOHEfU=; X-YMail-OSG: aVJaDR8VM1nZO3qfUuy7f3Iw94SkKxK0k0_VznvMEq2Wyl5 4jje54rbykIJTpo5DsigSm6oMnSPvN_JxN0Wtud2.zG6FjnKqkoOKHpiDZZx pneIGKr9nBc5EeEAKLmA8X4YCvCSzsoduOPyvv1WbYaaEh4w4iKr36aAl73. 8gAkbdiGCQG9iLksraEL5hkDxmu6n.GQcI9_Wqv0R1C.vpRpHO93YWDPgtRE p0PnnIW9Nx.c4DPGEWpKpTvLDcsPxypJzVN82W8kfEuXcUybNzQ_SU9.f.5r 9XsyNeUNsi.RcUSXGZcqQOqBjbljHWK9tvVIyFr_4zYukhzUmtwL7ela6x9F M2k6vZ1WXGto68cfSMMSzZTYXWWgzb7pu1GLHBQEy2_RV3lLwcF_ZKA-- Received: from [67.170.234.149] by web121712.mail.ne1.yahoo.com via HTTP; Tue, 02 Aug 2011 17:08:08 PDT X-Mailer: YahooMailWebService/0.8.112.310352 References: <001201cc504f$11f32e50$35d98af0$@devshock.com> Message-ID: <1312330088.11904.YahooMailNeo@web121712.mail.ne1.yahoo.com> Date: Tue, 2 Aug 2011 17:08:08 -0700 (PDT) From: lars hofhansl Reply-To: lars hofhansl Subject: Re: synchronous_commit off To: Anibal David Acosta , "pgsql-performance@postgresql.org" In-Reply-To: <001201cc504f$11f32e50$35d98af0$@devshock.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-212104951-1312330088=:11904" X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.704 tagged_above=-10 required=5 tests=BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.806 X-Spam-Level: X-Archive-Number: 201108/29 X-Sequence-Number: 44476 --0-212104951-1312330088=:11904 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable No: The commit has the same guarantees as a synchronous commit w.r.t. data = consistency. The commit can only fail (as a whole) due to hardware problems= or postgres backend crashes. =0A=0A=0AAnd yes: The client commit returns, = but the server can fail later and not persist the transaction and it will b= e lost (again as a whole).=0A=0AYour application should be able to tolerate= losing the latest committed transactions if you use this.=0A=0AThe differe= nce to fsync=3Doff is that a server crash will leave the database is a cons= istent state with just the latest transactions lost.=0A=0A=0A=0A___________= _____________________=0AFrom: Anibal David Acosta =0ATo: p= gsql-performance@postgresql.org=0ASent: Monday, August 1, 2011 6:29 AM=0ASu= bject: [PERFORM] synchronous_commit off=0A=0A=0ACan a transaction committed= asynchronously report an error, duplicate key or something like that, caus= ing a client with a OK transaction but server with a FAILED transaction.=0A= =A0=0AThanks --0-212104951-1312330088=:11904 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

No: The co= mmit has the same guarantees as a synchronous commit w.r.t. data consistenc= y. The commit can only fail (as a whole) due to hardware problems or postgr= es backend crashes.

And yes: The clien= t commit returns, but the server can fail later and not persist the transac= tion and it will be lost (again as a whole).

Your application= should be able to tolerate losing the latest committed transactions if you= use this.

The difference to fsync=3Doff is that a= server crash will leave the database is a consistent state with just the l= atest transactions lost.

From: Anibal David Acosta <aa@devshock.com>
To: pgsql-performance@postgresql= .org
Sent: Monday, Augu= st 1, 2011 6:29 AM
Subject:= [PERFORM] synchronous_commit off

<= div class=3D"yiv2121105660WordSection1">

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

&nb= sp;

Thanks

--0-212104951-1312330088=:11904--