On Sun, Dec 19, 2004 at 11:35:02PM +0200, Heikki Linnakangas wrote: > On Sun, 19 Dec 2004, Tom Lane wrote: > > >Heikki Linnakangas <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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?" ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
