From: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | "Scott Carey" <scott(at)richrelevance(dot)com>, jd(at)commandprompt(dot)com, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Create and drop temp table in 8.3.4 |
Date: | 2008-11-06 22:45:57 |
Message-ID: | dcc563d10811061445h32c5ad72o84f367d7cc3c6899@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, Nov 6, 2008 at 3:33 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>>>> "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)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?
Logic? Without write barriers in my file system an fsync request will
be immediately returned true, correct? That means that writes can
happen out of order, and a system crash could corrupt the file system.
Just seems kind of obvious to me.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Schuller | 2008-11-06 23:04:01 | Re: lru_multiplier and backend page write-outs |
Previous Message | Kevin Grittner | 2008-11-06 22:33:43 | Re: Create and drop temp table in 8.3.4 |