[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-admin
Subject:    Re: [ADMIN] hanging for 30sec when checkpointing
From:       "scott.marlowe" <scott.marlowe () ihs ! com>
Date:       2004-02-09 23:49:51
Message-ID: Pine.LNX.4.33.0402091644310.25915-100000 () css120 ! ihs ! com
[Download RAW message or body]

On Mon, 9 Feb 2004, Goulet, Dick wrote:

> Scott,
> 
> 	If you feel it is necessary to apologize for such a minor 
> infraction of polite etiquette please come on over to Oracle-L.  We have 
> harshness 10 times greater.  Probably because there are so many 
> practioners and so many different points of view.  We call them "Holy 
> Wars".  The current blazing one is on RAID, the good, the bad, and the 
> ugly. 

Hehe, I grew up on FIDO net, so I know all about the flammage... :-)

I can still remember the amiga versus atari ST holy wars of old.

> 	BTW: From a Holy War on Oracle-L of similar topic.  There is a 
> difference on how bad that lying IDE drive is depending on who the 
> vendor is, what system it's plugged into, and what OS is being used.  
> Some do a better job than others of "covering up" the lies.  The other 
> chap may have one of those better systems, so from his point of view 
> it's "old fashioned misinformation".  Doesn't mean it's not true, just 
> covered up better.  Kind of like "Air Freshener".

Well, it's interesting that during all the testing I and many others were 
doing last year, it appeared the escalade IDE RAID controllers were doing 
SOMETHING (no is quite sure if it was disabling write cache or not, but we 
guessed that was so) that made the IDE drives under them safe from the 
power off data loss issue that IDE drives seem to suffer from.

As for the OS, my guess is that some OSes probably just insert some delay 
between receiving an fsync notification from an IDE drive and reporting it 
back to the application or something like that, that makes them appear 
safe.  Such situations often result in systems that only fail under very 
heavy concurrent load, but pass the test under light to medium 
concurrency.

That said we have a really HUGE (~200 drive) IDE storage array my web / 
app server sits on top of.  No clue if that thing will reliably work under 
a database, and I'm in no hurry to find out.  

But since the fsync on WAL is all that seems important, I could always 
initlocation a big chunk of it and keep the WAL local and I should be ok.


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org
[prev in list] [next in list] [prev in thread] [next in thread]