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. 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly