Skip site navigation (1) Skip section navigation (2)

Re: Async Commit, v21 (now: v22)

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, <pgsql-patches(at)postgresql(dot)org>, "Bruce Momjian" <bruce(at)momjian(dot)us>
Subject: Re: Async Commit, v21 (now: v22)
Date: 2007-07-24 14:29:20
Message-ID: 87odi127un.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-patches
"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


In response to

Responses

pgsql-patches by date

Next:From: Simon RiggsDate: 2007-07-24 14:50:10
Subject: Re: Async Commit, v21 (now: v22)
Previous:From: Heikki LinnakangasDate: 2007-07-24 14:21:25
Subject: Re: Async Commit, v21 (now: v22)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group