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: Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Group commit, revised
Date: 2012-01-25 08:11:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
I've been thinking, what exactly is the important part of this group 
commit patch that gives the benefit? Keeping the queue sorted isn't all 
that important - XLogFlush() requests for commits will come in almost 
the correct order anyway.

I also don't much like the division of labour between groupcommit.c and 
xlog.c. XLogFlush() calls GroupCommitWaitForLSN(), which calls back 
DoXLogFlush(), which is a bit hard to follow. (that's in my latest 
version; the original patch had similar division but it also cut across 
processes, with the wal writer actually doing the flush)

It occurs to me that the WALWriteLock already provides much of the same 
machinery we're trying to build here. It provides FIFO-style queuing, 
with the capability to wake up the next process or processes in the 
queue. Perhaps all we need is some new primitive to LWLock, to make it 
do exactly what we need.

Attached is a patch to do that. It adds a new mode to 
LWLockConditionalAcquire(), LW_EXCLUSIVE_BUT_WAIT. If the lock is free, 
it is acquired and the function returns immediately. However, unlike 
normal LWLockConditionalAcquire(), if the lock is not free it goes to 
sleep until it is released. But unlike normal LWLockAcquire(), when the 
lock is released, the function returns *without* acquiring the lock.

I modified XLogFlush() to use that new function for WALWriteLock. It 
tries to get WALWriteLock, but if it's not immediately free, it waits 
until it is released. Then, before trying to acquire the lock again, it 
rechecks LogwrtResult to see if the record was already flushed by the 
process that released the lock.

This is a much smaller patch than the group commit patch, and in my 
pgbench-tools tests on my laptop, it has the same effect on performance. 
The downside is that it touches lwlock.c, which is a change at a lower 
level. Robert's flexlocks patch probably would've been useful here.

   Heikki Linnakangas

Attachment: groupcommit-with-special-lwlockmode-1.patch
Description: text/x-diff (7.6 KB)

In response to


pgsql-hackers by date

Next:From: Fujii MasaoDate: 2012-01-25 08:16:40
Subject: Re: Online base backup from the hot-standby
Previous:From: Hitoshi HaradaDate: 2012-01-25 08:07:55
Subject: Re: Patch: Allow SQL-language functions to reference parameters by parameter name

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