Tom Lane wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
> > On Sun, 19 Dec 2004, Alvaro Herrera wrote:
> >> This is not useful at all, because the objective of this exercise is to
> >> downgrade locks, from exclusive row locking (SELECT ... FOR UPDATE) to
> >> shared row locking.
>
> > Actually it might help in some scenarios. Remember, we're not talking
> > about upgrading shared locks to exclusive locks. We're only talking about
> > locking more rows than necessary (all rows).
>
> Nonetheless, it would mean that locks would be taken depending on
> implementation-dependent, not-visible-to-the-user considerations.
> Shared locks can still cause deadlocks, and so you would have an
> unreliable application, which would only be unreliable under load.
>
> As I said in connection with the other proposal, weird user-visible
> semantics should be the last resort not the first.
>
One idea is to stamp the same shared lock counter on multiple rows and
just prevent another application from also sharing that lock if too many
rows are locked. It would wait for the lock to be released. This
prevents the problem of having to store thousands of shared lock
counters. There would have to be some flag so say which shared counters
are only for a single backend.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073