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
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
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
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.
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
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
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
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
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,
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
10 matches
Mail list logo