On Mon, 2007-04-02 at 21:16 -0400, Tom Lane wrote:
> ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes:
> > Heikki Linnakangas <heikki@enterprisedb.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.
Itagaki-san:
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
