Skip site navigation (1) Skip section navigation (2)

Re: LWLock Queue Jumping

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: LWLock Queue Jumping
Date: 2009-08-29 23:28:14
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Aug 28, 2009 at 8:07 PM, Simon Riggs<simon(at)2ndquadrant(dot)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?


In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2009-08-30 06:03:23
Subject: Re: LWLock Queue Jumping
Previous:From: Marko TiikkajaDate: 2009-08-29 23:18:34
Subject: Re: Using results from INSERT ... RETURNING

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group