Re: LWLock Queue Jumping
От | Greg Stark |
---|---|
Тема | Re: LWLock Queue Jumping |
Дата | |
Msg-id | 407d949e0908291628q4d7523v18b7a59c08977989@mail.gmail.com обсуждение исходный текст |
Ответ на | LWLock Queue Jumping (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: LWLock Queue Jumping
|
Список | 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 по дате отправления: