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

Re: Async Commit, v21 (now: v22)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
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:55:04
Message-ID: 9664.1185288904@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
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 DunstanDate: 2007-07-24 14:57:12
Subject: Re: plperl warnings on win32
Previous:From: Simon RiggsDate: 2007-07-24 14:50:10
Subject: Re: Async Commit, v21 (now: v22)

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