On Sun, Dec 19, 2004 at 11:35:02PM +0200, Heikki Linnakangas wrote:
> On Sun, 19 Dec 2004, 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.
>
> I agree that lock escalation is not a good solution, we run into problems
> with DB2 lock escalation at work all the time.
Does anyone know how Oracle deals with this? They use MVCC like
PostgreSQL, so they'd be a better source for inspiration.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
