Re: synchronous_commit off

From: lars hofhansl <lhofhansl(at)yahoo(dot)com>
To: Anibal David Acosta <aa(at)devshock(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: synchronous_commit off
Date: 2011-08-03 00:08:08
Message-ID: 1312330088.11904.YahooMailNeo@web121712.mail.ne1.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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.

And yes: The client commit returns, but the server can fail later and not persist the transaction 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=off is that a server crash will leave the database is a consistent state with just the latest transactions lost.

________________________________
From: Anibal David Acosta <aa(at)devshock(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Sent: Monday, August 1, 2011 6:29 AM
Subject: [PERFORM] synchronous_commit off

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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message lars hofhansl 2011-08-03 00:16:26 Re: Which Join is better
Previous Message Gavin Flower 2011-08-02 23:01:58 Re: Tsearch2 - bad performance with concatenated ts-vectors