Kevin Grittner wrote:
With either platters or BBU cache,
the data is persisted on fsync; why do you see a risk with one but
not the other
Forgot to address this part. The troublesome sequence if you don't have
a BBU is:
1) WAL data is written to the OS cache
2) PG calls fsync
3) Data is tranferred into the drive's volatile, non battery-backed cache
4) Drive lies about data being on disk, says fsync is done
5) That 8K data page is written out to the OS cache, also with fsync,
then onto the drive. It says it has that too.
6) Due to current disk head location, 4KB of the data page gets written
out before it gets to the WAL data
7) System crashes
Now you're dead. You've just torn a data page, but not written any of
the data to the WAL necessary to reconstruct any valid version of that page.
I think Kevin's point here may be that if your fsync isn't reliable,
you're always in trouble. But if your fsync is good, even torn pages
should be repairable by the deltas written to the WAL, as I described in
the message I just sent before this one. That's true regardless of
whether you achieved "non-lying fsync" with a BBU or by turning a
drive's write cache off. There's nothing really special about the BBU
beyond it behind the most common form of reliable write cache that
works. You get the same properties at a slower rate with a drive that's
configured to never lie about writes.
--
Greg Smith 2ndQuadrant US greg@xxxxxxxxxxxxxxx Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
