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

CheckpointStartLock starvation

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: CheckpointStartLock starvation
Date: 2007-04-02 19:00:03
Message-ID: 461152B3.5060404@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
I'm seeing a problem on my benchmark machine: checkpoints stop happening 
after the ramp-up period.

It looks like the bgwriter gets starved waiting on the 
CheckpointStartLock. The CheckpointStartLock is held in shared mode over 
an XLogFlush when committing, which on an extremely busy system like a 
benchmark is always long enough to have a new transaction to acquire the 
CheckpointStartLock again.

I'm running another test with more logging to confirm that's what's 
happening, but I'm pretty sure that's it...

As a proposed fix, instead of acquiring the CheckpointStartLock in 
RecordTransactionCommit, we set a flag in MyProc saying "commit in 
progress". Checkpoint will scan through the procarray and make note of 
any commit in progress transactions, after computing the new redo record 
ptr, and wait for all of them to finish before flushing clog.

Unless someone has a better idea, I'll write a patch to do the above.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2007-04-02 19:22:08
Subject: Is this portable?
Previous:From: Zdenek KotalaDate: 2007-04-02 18:55:11
Subject: Questions about pid file creation code

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