pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Scott Marlowe <scott.marlowe@gmail.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: jd@commandprompt.com, pgsql-performance@postgresql.org, "Scott Carey" <scott@richrelevance.com>
Subject: Re: Create and drop temp table in 8.3.4
Date: Thu, 6 Nov 2008 17:03:58 -0700
Message-ID: <dcc563d10811061603t574c74afj4f651c4ec7dbb88d@mail.gmail.com> (raw)
In-Reply-To: <49132383.EE98.0025.0@wicourts.gov>
References: <4911957A.EE98.0025.0@wicourts.gov>
	<4911D4DB.EE98.0025.0@wicourts.gov>
	<4912EAFF.EE98.0025.0@wicourts.gov>
	<1225999071.1204.14.camel@jd-laptop.pragmaticzealot.org>
	<4912F29E.EE98.0025.0@wicourts.gov>
	<a1ec7d000811061305n7b28800od469c1411e1a9928@mail.gmail.com>
	<dcc563d10811061405l76cb59adh58741b227fe9d8a6@mail.gmail.com>
	<49131C67.EE98.0025.0@wicourts.gov>
	<dcc563d10811061445h32c5ad72o84f367d7cc3c6899@mail.gmail.com>
	<49132383.EE98.0025.0@wicourts.gov>

On Thu, Nov 6, 2008 at 4:04 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
>>>> "Scott Marlowe" <scott.marlowe@gmail.com> wrote:
>> On Thu, Nov 6, 2008 at 3:33 PM, Kevin Grittner
>> <Kevin.Grittner@wicourts.gov> wrote:
>>>>>> "Scott Marlowe" <scott.marlowe@gmail.com> wrote:
>>>> I am pretty sure that with no write barriers that even a BBU
>>> hardware
>>>> caching raid controller cannot guarantee your data.
>>>
>>> That seems at odds with this:
>>>
>>> http://oss.sgi.com/projects/xfs/faq.html#wcache_persistent
>>>
>>> What evidence to you have that the SGI XFS team is wrong?
>>
>> Without write barriers in my file system an fsync request will
>> be immediately returned true, correct?
>
> Not as I understand it; although it will be pretty fast if it all fits
> into the battery backed cache.

OK, thought exercise time.  There's a limited size for the cache.
Let's assume it's much smaller, say 16Megabytes.  We turn off write
barriers.  We start writing data to the RAID array faster than the
disks can write it.  At some point, the data flowing into the cache is
backing up into the OS.  Without write barriers, the second we call an
fsync it returns true.  But the data's not in the cache yet, or on the
disk.  Machine crashes, data is incoherent.

But that's assuming write barriers work as I understand them.



view thread (17+ messages)  latest in thread

Message-ID: <dcc563d10811061603t574c74afj4f651c4ec7dbb88d@mail.gmail.com>
Permalink:  ../dcc563d10811061603t574c74afj4f651c4ec7dbb88d@mail.gmail.com/
Also on:    postgresql.org/message-id/dcc563d10811061603t574c74afj4f651c4ec7dbb88d@mail.gmail.com

 · 

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: scott.marlowe@gmail.com, Kevin.Grittner@wicourts.gov, scott@richrelevance.com
  Subject: Re: Create and drop temp table in 8.3.4
  In-Reply-To: <dcc563d10811061603t574c74afj4f651c4ec7dbb88d@mail.gmail.com>

* 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