Re: CheckpointStartLock starvation

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
signaling.

regards, tom lane