Re: Async Commit, v21 (now: v22)

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