Re: LWLock Queue Jumping - Mailing list pgsql-hackers

From Greg Stark
Subject Re: LWLock Queue Jumping
Date
Msg-id 407d949e0908291628q4d7523v18b7a59c08977989@mail.gmail.com
Whole thread Raw
In response to LWLock Queue Jumping  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: LWLock Queue Jumping  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Fri, Aug 28, 2009 at 8:07 PM, Simon Riggs<simon@2ndquadrant.com> wrote:
> WALInsertLock is heavily contended and likely always will be even if we
> apply some of the planned fixes.

I've lost any earlier messages, could you resend the raw data on which
this is based?

> Some callers of WALInsertLock are more important than others
>
> * Writing new Clog or Multixact pages (serialized by ClogControlLock)
> * For Hot Standby, writing SnapshotData (serialized by ProcArrayLock)
>
> In these cases it seems like we can skip straight to the front of the
> WALInsertLock queue without problem.

How does re-ordering reduce the contention? We reorder shared lockers
ahead of exclusive lockers because they can all hold the lock at the
same time so we can reduce the amount of time the lock is held.

Reordering some exclusive lockers ahead of other exclusive lockers
won't reduce the amount of time the lock is held at all. Are you
saying the reason to do it is to reduce time spent waiting on this
lock while holding other critical locks? Do we have tools to measure
how long is being spent waiting on one lock while holding another lock
so we can see if there's a problem and whether this helps?

-- 
greg
http://mit.edu/~gsstark/resume.pdf


pgsql-hackers by date:

Previous
From: Marko Tiikkaja
Date:
Subject: Re: Using results from INSERT ... RETURNING
Next
From: Heikki Linnakangas
Date:
Subject: Re: LWLock Queue Jumping