pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Karl Denninger <karl@denninger.net>
To: Scott Marlowe <scott.marlowe@gmail.com>
Cc: Brad Nicholson <bnichols@ca.afilias.info>
Cc: Greg Smith <greg@2ndquadrant.com>
Cc: Scott Carey <scott@richrelevance.com>
Cc: Michael March <mmarch@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD
Date: Tue, 10 Aug 2010 13:38:08 -0500
Message-ID: <4C619C90.3090005@denninger.net> (raw)
In-Reply-To: <AANLkTi=pehZj1Bb8KVusGykyEzWn__pif-87Tz2beJYj@mail.gmail.com>
References: <AANLkTikXLYc32Jyr5Fb8VeVNt6R86mCcF+0CkTHALd8W@mail.gmail.com>
	<BAE01AAD-6C69-48C7-BD2E-77E463D49903@richrelevance.com>
	<AANLkTi=km+H+mZ=yyx0_HTFZ-yU2sh85D+p5cs+ZcUSF@mail.gmail.com>
	<A1640F99-A7C5-4F04-9A25-782C46BE7DAB@richrelevance.com>
	<4C617C80.9080509@2ndquadrant.com>
	<4C619300.3080400@ca.afilias.info>
	<4C6196DB.8050307@denninger.net>
	<AANLkTi=pehZj1Bb8KVusGykyEzWn__pif-87Tz2beJYj@mail.gmail.com>

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

Attachments:

karl.vcf (text/x-vcard, 122B) download begin:vcard fn:Karl Denninger n:Denninger;Karl email;internet:karl@denninger.net x-mozilla-html:TRUE version:2.1 end:vcard

view thread (37+ messages)  latest in thread

Message-ID: <4C619C90.3090005@denninger.net>
Permalink:  ../4C619C90.3090005@denninger.net/
Also on:    postgresql.org/message-id/4C619C90.3090005@denninger.net

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: karl@denninger.net, scott.marlowe@gmail.com, bnichols@ca.afilias.info, greg@2ndquadrant.com, scott@richrelevance.com, mmarch@gmail.com
  Subject: Re: Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD
  In-Reply-To: <4C619C90.3090005@denninger.net>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox