Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 811C56330FA for ; Tue, 10 Aug 2010 15:39:02 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 75680-01 for ; Tue, 10 Aug 2010 18:38:54 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mail.postgresql.org (Postfix) with ESMTP id E28CB633C1A for ; Tue, 10 Aug 2010 15:38:54 -0300 (ADT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by FS.denninger.net (8.14.4/8.13.1) with ESMTP id o7AIcsm4016325 for ; Tue, 10 Aug 2010 13:38:54 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Tue Aug 10 13:38:54 2010 Message-ID: <4C619C90.3090005@denninger.net> Date: Tue, 10 Aug 2010 13:38:08 -0500 From: Karl Denninger User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Marlowe CC: Brad Nicholson , Greg Smith , Scott Carey , Michael March , "pgsql-performance@postgresql.org" Subject: Re: Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD References: <4C617C80.9080509@2ndquadrant.com> <4C619300.3080400@ca.afilias.info> <4C6196DB.8050307@denninger.net> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------080001070002020509050006" X-Antivirus: avast! (VPS 100810-0, 08/10/2010), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.783 tagged_above=-10 required=5 tests=BAYES_50=0.8, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982 X-Spam-Level: * X-Archive-Number: 201008/118 X-Sequence-Number: 39961 This is a multi-part message in MIME format. --------------080001070002020509050006 Content-Type: multipart/alternative; boundary="------------030607020302080907060601" --------------030607020302080907060601 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Scott Marlowe wrote: > On Tue, Aug 10, 2010 at 12:13 PM, Karl Denninger wrote: > >> ANY disk that says "write is complete" when it really is not is entirely >> unsuitable for ANY real database use. It is simply a matter of time >> > > What about read only slaves where there's a master with 100+spinning > hard drives "getting it right" and you need a half dozen or so read > slaves? I can imagine that being ok, as long as you don't restart a > server after a crash without checking on it. > A read-only slave isn't read-only, is it? I mean, c'mon - how does the data get there? IF you mean "a server that only accepts SELECTs, does not accept UPDATEs or INSERTs, and on a crash **reloads the entire database from the master**", then ok. Most people who will do this won't reload it after a crash. They'll "inspect" the database and say "ok", and put it back online. Bad Karma will ensue in the future. Incidentally, that risk is not theoretical either (I know about this one from hard experience. Fortunately the master was still ok and I was able to force a full-table copy.... I didn't like it as the database was a few hundred GB, but I had no choice.) -- Karl --------------030607020302080907060601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Scott Marlowe wrote: 
On Tue, Aug 10, 2010 at 12:13 PM, Karl Denninger <karl@denninger.net> wrote:
  
ANY disk that says "write is complete" when it really is not is entirely
unsuitable for ANY real database use.  It is simply a matter of time
    

What about read only slaves where there's a master with 100+spinning
hard drives "getting it right" and you need a half dozen or so read
slaves?  I can imagine that being ok, as long as you don't restart a
server after a crash without checking on it.
A read-only slave isn't read-only, is it?

I mean, c'mon - how does the data get there?

IF you mean "a server that only accepts SELECTs, does not accept UPDATEs or INSERTs, and on a crash **reloads the entire database from the master**", then ok.

Most people who will do this won't reload it after a crash.  They'll "inspect" the database and say "ok", and put it back online.  Bad Karma will ensue in the future.

Incidentally, that risk is not theoretical either (I know about this one from hard experience.  Fortunately the master was still ok and I was able to force a full-table copy.... I didn't like it as the database was a few hundred GB, but I had no choice.)

-- Karl
--------------030607020302080907060601-- --------------080001070002020509050006 Content-Type: text/x-vcard; charset=utf-8; name="karl.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="karl.vcf" begin:vcard fn:Karl Denninger n:Denninger;Karl email;internet:karl@denninger.net x-mozilla-html:TRUE version:2.1 end:vcard --------------080001070002020509050006--