Re: Data Corruption in case of abrupt failure

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Keith C(dot) Perry" <netadmin(at)vcsn(dot)com>, Stephen Robert Norris <srn(at)commsecure(dot)com(dot)au>, satish satish <satish_ach2003(at)yahoo(dot)com>, <pgsql-general(at)postgresql(dot)org>
Subject: Re: Data Corruption in case of abrupt failure
Date: 2004-03-17 16:27:05
Message-ID: Pine.LNX.4.33.0403170925560.10668-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, 16 Mar 2004, Tom Lane wrote:

> "Keith C. Perry" <netadmin(at)vcsn(dot)com> writes:
> > I've read threads like this before and because I've never lost data on
> > servers with IDE drives after doing some basic torture tests
> > (e.g. pulling the plug in the middle of an update et al), I don't
> > think I've paid close enough attention.
>
> On many IDE drives it is possible to turn write caching on and off with
> some incantation involving "hdparm" (don't have the details but you can
> probably find 'em in the list archives). Possibly your system is
> already configured safely.

hdparm -W0 /dev/hda

> > Is there some definite way someone can test their IDE drives so see
> > whether or not they are "lying" about write completions?
>
> What I'd suggest is to set up a simple test involving a long string of
> very small transactions (a bunch of separate INSERTs into a table with
> no indexes works fine). Time it twice, once with "fsync" enabled and
> once without. If there's not a huge difference, your drive is lying.

pgbench is a nice candidate for this.

pgbench -c 100 -t 100000

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2004-03-17 16:41:31 Re: Data Corruption in case of abrupt failure
Previous Message Tom Lane 2004-03-17 16:07:42 Re: Newbie question: OT