| From: | Matthew Wakeling <matthew(at)flymine(dot)org> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
| Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Proposal of tunable fix for scalability of 8.4 |
| Date: | 2009-03-18 11:45:47 |
| Message-ID: | alpine.DEB.2.00.0903181141000.21772@aragorn.flymine.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, 18 Mar 2009, Simon Riggs wrote:
> I agree with that, apart from the "granting no more" bit.
>
> The most useful behaviour is just to have two modes:
> * exclusive-lock held - all other x locks welcome, s locks queue
> * shared-lock held - all other s locks welcome, x locks queue
The problem with making all other locks welcome is that there is a
possibility of starvation. Imagine a case where there is a constant stream
of shared locks - the exclusive locks may never actually get hold of the
lock under the "all other shared locks welcome" strategy. Likewise with
the reverse.
Taking a snapshot and queueing all newer locks forces fairness in the
locking strategy, and avoids one of the sides getting starved.
Matthew
--
I've run DOOM more in the last few days than I have the last few
months. I just love debugging ;-) -- Linus Torvalds
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthew Wakeling | 2009-03-18 11:49:33 | Re: Proposal of tunable fix for scalability of 8.4 |
| Previous Message | Gregory Stark | 2009-03-18 11:36:18 | Re: Proposal of tunable fix for scalability of 8.4 |