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 E2C359DCA79 for ; Sat, 11 Mar 2006 14:26:39 -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 15208-05 for ; Sat, 11 Mar 2006 14:26:39 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from obelix.askesis.nl (laudanum.demon.nl [82.161.125.16]) by postgresql.org (Postfix) with ESMTP id 6236A9DC867 for ; Sat, 11 Mar 2006 14:26:36 -0400 (AST) Received: obelix 172.31.0.1 from 172.31.1.4 172.31.1.4 via HTTP with MS-WebStorage 6.0.6249 Received: from panoramix by obelix; 11 Mar 2006 19:26:36 +0100 Subject: Re: x206-x225 From: Joost Kraaijeveld To: Tom Lane Cc: PFC , David Lang , Richard Huxton , pgsql-performance@postgresql.org In-Reply-To: <28030.1142096369@sss.pgh.pa.us> References: <441181C6.3040401@archonet.com> <1142063378.6634.13.camel@localhost> <1142065029.6634.23.camel@localhost> <1142087174.6634.32.camel@localhost> <28030.1142096369@sss.pgh.pa.us> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 11 Mar 2006 19:26:36 +0100 Message-Id: <1142101596.6634.50.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.093 required=5 tests=[AWL=0.092, UNPARSEABLE_RELAY=0.001] X-Spam-Score: 0.093 X-Spam-Level: X-Archive-Number: 200603/153 X-Sequence-Number: 17590 On Sat, 2006-03-11 at 11:59 -0500, Tom Lane wrote: > 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. Maybe I should have expressed myself better. The parent post said: > It depends if you consider that "written to the disk" means "data is > somewhere between the OS cache and the platter" or "data is written on > the platter and will survive a power loss". > > Postgres wants the second option, of course. With my remark I meant that the only thing *PostgreSQL* can expect is that the data is out of the OS: there is no greater guarantee in the fsync function. If the *database administrator* wants better guarantees, he (or she) better read your advise. > 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. Yep, the drives have a write cache, and indeed, they are not backed up by a battery (neither is my RAID controller) but as this is a test/development machine, I don't really care. You made me rethink my production machine thought. I will have to check the drives and the state of their write cache of that machine. Thanks for that. -- Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 e-mail: J.Kraaijeveld@Askesis.nl web: www.askesis.nl