X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id B12449DCA79 for ; Sat, 11 Mar 2006 12:59:38 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 99440-03 for ; Sat, 11 Mar 2006 12:59:37 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 417499DCA4F for ; Sat, 11 Mar 2006 12:59:35 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id k2BGxTr1028031; Sat, 11 Mar 2006 11:59:29 -0500 (EST) To: Joost Kraaijeveld cc: PFC , David Lang , Richard Huxton , pgsql-performance@postgresql.org Subject: Re: x206-x225 In-reply-to: <1142087174.6634.32.camel@localhost> References: <441181C6.3040401@archonet.com> <1142063378.6634.13.camel@localhost> <1142065029.6634.23.camel@localhost> <1142087174.6634.32.camel@localhost> Comments: In-reply-to Joost Kraaijeveld message dated "Sat, 11 Mar 2006 15:26:14 +0100" Date: Sat, 11 Mar 2006 11:59:29 -0500 Message-ID: <28030.1142096369@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.112 required=5 tests=[AWL=0.112] X-Spam-Score: 0.112 X-Spam-Level: X-Archive-Number: 200603/152 X-Sequence-Number: 17589 Joost Kraaijeveld writes: > I assume that for PostgreSQL "written to disk" is after fsync returned > successfully. In practice that could very well mean that the data is > still in a cache somewhere (controller or harddisk, not in the OS > anymore, see also man page of fsync) What it had better mean, if you want your database to be reliable, is that the data is stored someplace that will survive a system crash (power outage, kernel panic, etc). A battery-backed RAM cache is OK, assuming that total failure of the RAID controller is not one of the events you consider likely enough to need protection against. The description of your SATA drive makes it sound like the drive does not put data on the platter before reporting "write complete", but only stores it in on-board RAM cache. It is highly unlikely that there is any battery backing for that cache, and therefore that drive is not to be trusted. regards, tom lane