On 02/08/2010 21:14, John R Pierce wrote:
> Another factor, if your linux system was using LVM (its the default
> storage configuration on many distributions), there's a pretty good
> chance the drive mapper is ignoring write barriers, which greatly speeds
> up random writes at the expense of reliable commits.
A lot has been discussed about how well LVM plays with PostgreSQL.
But for sure, write barriers are not related to commits. A reliable
commit is about disks synchronously flushing their caches to platters
(and of course, before that, OS cache being flushed to disk cache, which
is the easy part).
In ACID terms, write barries help with C, not with D. Actually, a write
barrier is kind of the opposite of a flush, it's a "don't flush this
before that". It enforces an order on writes, but doesn't enforce their
immediate execution.
Of course, if the disk _doesn't_ support write barriers, poor's man
workaround is to enforce a complete flush instead.
AFAIK, there's no POSIX API to request a write barrier at application
level. There's only the sync (i.e. flush) related API. And I'm pretty
sure PostegreSQL issues the right syncs at the right times.
LVM correctly reports it doesn't support write barriers. The FS then
knows what to do (issue a full flush instead), and no harm is done
(because not all disks support wbs, the code to handle that case has to
be there in the FS). The FS just runs slower. But just as safe as
without LVM.
And since PostgreSQL issues syncs (or uses synchronous APIs), there's
little point discussing of wbs here, since it's all about flushing. Wbs
are issued by the FS in order to _avoid_ a flush: the FS major concern
is C, not D; but when it's the application requesting a flush, the flush
can't be avoided, and wbs are almost useless.
.TM.
