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

Re: Group commit, revised

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Group commit, revised
Date: 2012-01-17 17:37:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 17.01.2012 16:35, Peter Geoghegan wrote:
> On 16 January 2012 08:11, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com>  wrote:
>> I think it might be simpler if it wasn't the background writer that's
>> responsible for "driving" the group commit queue, but the backends
>> themselves. When a flush request comes in, you join the queue, and if
>> someone else is already doing the flush, sleep until the driver wakes you
>> up. If no-one is doing the flush yet (ie. the queue is empty), start doing
>> it yourself. You'll need a state variable to keep track who's driving the
>> queue, but otherwise I think it would be simpler as there would be no
>> dependency on WAL writer.
> I think this replaces one problem with another. You've now effectively
> elevated a nominated backend to the status of an auxiliary process -
> do you intend to have the postmaster look after it, as with any other
> auxiliary process?

The GroupCommitWaitForLSN() call happens within a critical section. If 
the process dies, you're screwed no matter what. It's not very different 
from the current situation where if one backend flushes the WAL, another 
backend will notice that once it gets the WALWriteLock, and returns quickly.

>> wal_writer_delay is still needed for controlling how often asynchronous
>> commits are flushed to disk.
> That had occurred to me of course, but has anyone ever actually
> tweaked wal_writer_delay with adjusting the behaviour of asynchronous
> commits in mind?

I found it very helpful to reduce wal_writer_delay in pgbench tests, 
when running with synchronous_commit=off. The reason is that hint bits 
don't get set until the commit record is flushed to disk, so making the 
flushes more frequent reduces the contention on the clog. However, Simon 
made async commits nudge WAL writer if the WAL page fills up, so I'm not 
sure how relevant that experience is anymore.

   Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Greg SmithDate: 2012-01-17 18:08:48
Subject: Re: Patch: add timing of buffer I/O requests
Previous:From: Marti RaudseppDate: 2012-01-17 17:35:51
Subject: Patch review for logging hooks (CF 2012-01)

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