Re: [HACKERS] CheckpointStartLock starvation

2007-04-04 Thread Simon Riggs
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 XLo

Re: [HACKERS] CheckpointStartLock starvation

2007-04-03 Thread Heikki Linnakangas
Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> writes: Tom Lane wrote: Nor will that work for prepared xacts --- you don't want to wait for the eventual commit, only for PREPARE TRANSACTION to exit its critical section. PREPARE TRANSACTION wouldn't set the flag in MyProc; there's no c

Re: [HACKERS] CheckpointStartLock starvation

2007-04-03 Thread Tom Lane
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Nor will that work for prepared xacts --- you don't want to wait for the >> eventual commit, only for PREPARE TRANSACTION to exit its critical >> section. > PREPARE TRANSACTION wouldn't set the flag in MyProc; there's no clog > c

Re: [HACKERS] CheckpointStartLock starvation

2007-04-03 Thread Heikki Linnakangas
Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> writes: Tom Lane wrote: What sort of "wait for finish" mechanism do you have in mind? I was thinking of XactLockTableWait. Ugh. I don't think the bgwriter can participate in heavyweight-lockmgr operations, or should become able to.

Re: [HACKERS] CheckpointStartLock starvation

2007-04-02 Thread Tom Lane
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 lik

Re: [HACKERS] CheckpointStartLock starvation

2007-04-02 Thread ITAGAKI Takahiro
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

Re: [HACKERS] CheckpointStartLock starvation

2007-04-02 Thread Tom Lane
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> What sort of "wait for finish" mechanism do you have in mind? > I was thinking of XactLockTableWait. Ugh. I don't think the bgwriter can participate in heavyweight-lockmgr operations, or should become able to. Nor will that wor

Re: [HACKERS] CheckpointStartLock starvation

2007-04-02 Thread Heikki Linnakangas
Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> writes: As a proposed fix, instead of acquiring the CheckpointStartLock in RecordTransactionCommit, we set a flag in MyProc saying "commit in progress". Checkpoint will scan through the procarray and make note of any commit in progress tra

Re: [HACKERS] CheckpointStartLock starvation

2007-04-02 Thread Tom Lane
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > As a proposed fix, instead of acquiring the CheckpointStartLock in > RecordTransactionCommit, we set a flag in MyProc saying "commit in > progress". Checkpoint will scan through the procarray and make note of > any commit in progress transactions,

[HACKERS] CheckpointStartLock starvation

2007-04-02 Thread Heikki Linnakangas
I'm seeing a problem on my benchmark machine: checkpoints stop happening after the ramp-up period. 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 lik