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

Re: CheckpointStartLock starvation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CheckpointStartLock starvation
Date: 2007-04-03 01:16:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> writes:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> wrote:
>> 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.

> If the starvation comes from giving unfair priorities on shared locks
> against exclusive locks, does the below TODO item help us?

Tweaking the lock rules was my first thought too, but the side-effects
might be undesirable.  In this particular case it would certainly be
better to not have a lock at all, since having checkpoint block commits
even briefly is not what we'd like.  I think Heikki's plan of having
backends show in PGPROC that they're in a commit critical section is
basically sound, we just have to get the details straight.

Since checkpoint doesn't need to be instantaneous, it's probably
sufficient to just have it sleep 10 msec or so and recheck to see
if all the blockers are gone, instead of doing any kind of fancy

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2007-04-03 01:21:16
Subject: Re: Feature thought: idle in transaction timeout
Previous:From: Tom LaneDate: 2007-04-03 01:09:24
Subject: Re: Modifying TOAST thresholds

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