Re: Data Corruption in case of abrupt failure - Mailing list pgsql-general

From scott.marlowe
Subject Re: Data Corruption in case of abrupt failure
Date
Msg-id Pine.LNX.4.33.0403170925560.10668-100000@css120.ihs.com
Whole thread Raw
In response to Re: Data Corruption in case of abrupt failure  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Data Corruption in case of abrupt failure
Re: Data Corruption in case of abrupt failure
List pgsql-general
On Tue, 16 Mar 2004, Tom Lane wrote:

> "Keith C. Perry" <netadmin@vcsn.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


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Newbie question: OT
Next
From: Tom Lane
Date:
Subject: Re: Data Corruption in case of abrupt failure