From: Jon Schewe <jpschewe@mtu.net>
To: Scott Marlowe <scott.marlowe@gmail.com>
Cc: Greg Smith <greg@2ndquadrant.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: How filesystems matter with PostgreSQL
Date: Sat, 05 Jun 2010 18:58:58 -0500
Message-ID: <4C0AE4C2.5020309@mtu.net> (raw)
In-Reply-To: <AANLkTinRedcd5JaZRNphubdrVPlz7NXBkxgjeg4GLV0J@mail.gmail.com>
References: <4C08EEDF.7090403@mtu.net>
<4C0AD180.90607@2ndquadrant.com>
<4C0AD280.5020105@mtu.net>
<4C0AD547.2040308@2ndquadrant.com>
<4C0AD7DF.1030705@mtu.net>
<AANLkTinRedcd5JaZRNphubdrVPlz7NXBkxgjeg4GLV0J@mail.gmail.com>
On 06/05/2010 06:54 PM, Scott Marlowe wrote:
> On Sat, Jun 5, 2010 at 5:03 PM, Jon Schewe <jpschewe@mtu.net> wrote:
>
>>
>> On 06/05/2010 05:52 PM, Greg Smith wrote:
>>
>>> Jon Schewe wrote:
>>>
>>>>> If that's the case, what you've measured is which filesystems are
>>>>> safe because they default to flushing drive cache (the ones that take
>>>>> around 15 minutes) and which do not (the ones that take >=around 2
>>>>> hours). You can't make ext3 flush the cache correctly no matter what
>>>>> you do with barriers, they just don't work on ext3 the way PostgreSQL
>>>>> needs them to.
>>>>>
>>>>>
>>>>>
>>>> So the 15 minute runs are doing it correctly and safely, but the slow
>>>> ones are doing the wrong thing? That would imply that ext3 is the safe
>>>> one. But your last statement suggests that ext3 is doing the wrong
>>>> thing.
>>>>
>>>>
>>> I goofed and reversed the two times when writing that. As is always
>>> the case with this sort of thing, the unsafe runs are the fast ones.
>>> ext3 does not ever do the right thing no matter how you configure it,
>>> you have to compensate for its limitations with correct hardware setup
>>> to make database writes reliable.
>>>
>>>
>> OK, so if I want the 15 minute speed, I need to give up safety (OK in
>> this case as this is just research testing), or see if I can tune
>> postgres better.
>>
> Or use a trustworthy hardware caching battery backed RAID controller,
> either in RAID mode or JBOD mode.
>
Right, because the real danger here is if the power goes out you can end
up with a scrambled database, correct?
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: jpschewe@mtu.net, scott.marlowe@gmail.com, greg@2ndquadrant.com
Subject: Re: How filesystems matter with PostgreSQL
In-Reply-To: <4C0AE4C2.5020309@mtu.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