Andres Freund wrote:
> On Sunday 31 October 2010 20:59:31 Greg Smith wrote:
>> Writes only are sync'd out when you do a commit, or the database does a
> Hm? WAL is written out to disk after an the space provided by wal_buffers(def
> 8) * XLOG_BLCKSZ (def 8192) is used. The default is 64kb which you reach
> pretty quickly - especially after a checkpoint.
Fair enough; I'm so used to bumping wal_buffers up to 16MB nowadays that
I forget sometimes that people actually run with the default where this
becomes an important consideration.
> Not having a real O_DSYNC on linux until recently makes it even more dubious
> to have it as a default...
If Linux is now defining O_DSYNC, and it's buggy, that's going to break
more software than just PostgreSQL. It wasn't defined before because it
didn't work. If the kernel developers have made changes to claim it's
working now, but it doesn't really, I would think they'd consider any
reports of actual bugs here as important to fix. There's only so much
the database can do in the face of incorrect information reported by the
Anyway, I haven't actually seen reports that proves there's any problem
here, I was just pointing out that we haven't seen any positive reports
about database stress testing on these kernel versions yet either. The
changes here are theoretically the right ones, and defaulting to safe
writes that flush out write caches is a long-term good thing.
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
In response to
pgsql-performance by date
|Next:||From: Marti Raudsepp||Date: 2010-11-05 21:21:50|
|Subject: Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?|
|Previous:||From: Scott Marlowe||Date: 2010-11-05 20:59:47|
|Subject: Re: Major Linux performance regression; shouldn't we be
worried about RHEL6?|