From: Joost Kraaijeveld <J.Kraaijeveld@Askesis.nl>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PFC <lists@peufeu.com>
Cc: David Lang <david@lang.hm>
Cc: Richard Huxton <dev@archonet.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: x206-x225
Date: Sat, 11 Mar 2006 19:26:36 +0100
Message-ID: <1142101596.6634.50.camel@localhost> (raw)
In-Reply-To: <28030.1142096369@sss.pgh.pa.us>
References: <GMEAJIDMNDKCIHMMHDFLCEKHDHAA.hjs@rmax.nl>
<441181C6.3040401@archonet.com>
<1142063378.6634.13.camel@localhost>
<Pine.LNX.4.62.0603102355550.23148@qnivq.ynat.uz>
<1142065029.6634.23.camel@localhost>
<op.s58yeob1cigqcu@apollo13>
<1142087174.6634.32.camel@localhost>
<28030.1142096369@sss.pgh.pa.us>
On Sat, 2006-03-11 at 11:59 -0500, Tom Lane wrote:
> Joost Kraaijeveld <J.Kraaijeveld@Askesis.nl> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: J.Kraaijeveld@Askesis.nl, tgl@sss.pgh.pa.us, lists@peufeu.com, david@lang.hm, dev@archonet.com
Subject: Re: x206-x225
In-Reply-To: <1142101596.6634.50.camel@localhost>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox