Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Sure: the advantage is that the backends (ie, user query processing)
>> don't get blocked on fsync's. This is not really different from the
>> rationale for having the bgwriter.
> I'm puzzled though. How do they not get blocked on fsyncs? They can't proceed
> past their commit until the fsync happens whether they do it themselves or the
> walwriter does it.
Sure, they'll block on an fsync when they commit. Even then, the
walwriter can be an advantage if it's already flushed previous WAL
blocks: writing and flushing one page of WAL is faster than writing
and flushing a lot of pages, no?
>> It's probably most useful for large transactions, which up to now generally
>> had to stop and flush the WAL buffers every few pages worth of WAL output.
> That could be useful though the backend doesn't have to fsync when it writes
> out those buffers, does it?
A lot of systems seem to favor synchronous write methods for WAL, in
which you effectively *do* fsync when you write. There's also the
problem that if you have to write a dirty buffer, you must first ensure
WAL is fsync'd up through its LSN. (So to some extent this is also
offloading work from the bgwriter.)
regards, tom lane
In response to
pgsql-patches by date
|Next:||From: Andrew Dunstan||Date: 2007-07-24 14:57:12|
|Subject: Re: plperl warnings on win32|
|Previous:||From: Simon Riggs||Date: 2007-07-24 14:50:10|
|Subject: Re: Async Commit, v21 (now: v22)|