On Mon, 2007-04-02 at 21:16 -0400, Tom Lane wrote:
> ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> > Heikki Linnakangas <[EMAIL PROTECTED]> 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. 


Tried that way of handling the problem in June last year and it just
moved the problem, rather than removing it. Lock free solution is the
only way, so Heikki's method is better, ISTM.

  Simon Riggs             
  EnterpriseDB   http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to