X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 906C511F60B1 for ; Thu, 27 Apr 2006 03:59:34 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 62534-04 for ; Thu, 27 Apr 2006 03:59:24 -0300 (ADT) X-Greylist: delayed 00:27:49.710065 by SQLgrey- Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id 1603B11F624A for ; Thu, 27 Apr 2006 03:59:22 -0300 (ADT) Received: from ns2.nec.com.au (ns2.nec.com.au [147.76.180.2]) by svr4.postgresql.org (Postfix) with ESMTP id 8F1B95B58A9 for ; Thu, 27 Apr 2006 06:31:33 +0000 (GMT) Received: from ns2.nec.com.au ([127.0.0.1]) by localhost (ns2.nec.com.au [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26239-01-41 for ; Thu, 27 Apr 2006 16:31:26 +1000 (EST) Received: from smtp1.nec.com.au (unknown [172.31.8.18]) by ns2.nec.com.au (Postfix) with ESMTP id 21AC13B6A7 for ; Thu, 27 Apr 2006 16:31:26 +1000 (EST) Received: from eddy (eddy.ssd.neca.nec.com.au [147.76.48.116]) by warp.ssd.neca.nec.com.au (8.12.10+Sun/8.12.10) with SMTP id k3R6VOuP008411; Thu, 27 Apr 2006 16:31:24 +1000 (EST) Reply-To: From: "Guoping Zhang" To: Cc: "Guoping Zhang (E-mail)" Subject: how unsafe (or worst scenarios) when setting fsync OFF for postgresql Date: Thu, 27 Apr 2006 16:31:23 +1000 Message-ID: <003b01c669c4$34bbd7b0$74304c93@eddy> MIME-Version: 1.0 Content-Type: text/plain; charset="hz-gb-2312" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.644 tagged_above=0 required=5 tests=BAYES_20, SPF_SOFTFAIL X-Spam-Level: X-Archive-Number: 200604/627 X-Sequence-Number: 18711 Hi,. We are new to Postgresql. I am appreciated if the following question can be answered. Our application has a strict speed requirement for DB operation. Our tests show that it takes about 10secs for the operation when setting fsync off, but takes about 70 seconds when setting fsync ON (with other WAL related parametered tuned). We have to looking at setting fsync OFF option for performance reason, our questions are a) if we set fsync OFF and anything (very low chance though) like OS crash, loss of power, or hardware fault happened, can postgresql rolls back to the state that the last checkpoint was done ( but all the operations after that is lost) b) Does this roll back to last checkpoint can ensure the database back to consistent state? c) What is worst scenarios if setting fsync OFF in term of database safety. We try to avoid to restore the database from nightly backup. We view our application is not that data loss critical, say loss of five minutes of data and operation occasionally, but the database integrity and consistency must be kept. Can we set fsync OFF for the performance benefit, have the risk of only 5 minutes data loss or much worse? Thanks in advance. Regards, Guoping