Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.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
