Re: Async Commit, v21 (now: v22)

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> Without async commits? Do we really want the walwriter doing the
>> majority of the wal-flushing work for normal commits? It seems like
>> that's not going to be any advantage over just having some random
>> backend do the commit.
>
> 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.

> 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?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com