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.
- Heikki
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
