Re: tuning questions - Mailing list pgsql-performance

From Eric Soroos
Subject Re: tuning questions
Date
Msg-id 745F4B76-268E-11D8-848E-0003930F2A6C@soroos.net
Whole thread Raw
In response to Re: tuning questions  (Andrew Sullivan <andrew@libertyrms.info>)
List pgsql-performance
On Dec 4, 2003, at 10:11 AM, Andrew Sullivan wrote:

> On Thu, Dec 04, 2003 at 09:57:38AM -0800, Dror Matalon wrote:
>>
>> I've seen this comment several times from different people.
>> Would someone care to explain how you would get data corruption? I
>> thought that the whole idea of the log is to provide a journal similar
>> to what you get in a journaling file system.
>
>> So what am I missing in this picture?
>
> That a journalling file system can _also_ have file corruption if you
> have write caching enabled and no battery back up.  If the drive
> tells the OS, "Yep!  It's all on the disk!" bit it is _not_ actually
> scribed in the little bitty magnetic patterns -- and at that very
> moment, the power goes away -- the data that was reported to have been
> on the disk, but which was actually _not_ on the disk, is no longer
> anywhere.  (Well, except in the past.  But time travel was disabled
> some versions ago. ;-)

It's not just a theoretical problem.  It's happened to me on a laptop
drive in the last week or so.

I was testing out dbmail by hammering on it on Panther laptop, hfs+
journaling enabled, psql 7.4, latest and greatest.  I managed to hang
the system hard, requiring a reboot. Psql wouldn't start after the
crash, complaining of a damaged relation and helpfully telling me that
'you may need to restore from backup'.

No big deal on the data loss, since it was a test/hammering
installation. It would have been nice to be able to drop that relation
or prune the entire database, but I'm sure that would ultimately run
into referential integrity problems.

eric



pgsql-performance by date:

Previous
From: Jack Coates
Date:
Subject: Re: tuning questions
Next
From: Jeff
Date:
Subject: Re: Slow UPADTE, compared to INSERT