| From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Shared row locking |
| Date: | 2004-12-19 21:35:02 |
| Message-ID: | Pine.OSF.4.61.0412192330360.479956@kosh.hut.fi |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, 19 Dec 2004, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka(at)iki(dot)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.
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-12-19 23:42:11 | Kerberos includes (was Re: Port report: Fedora Core 3 x86_64) |
| Previous Message | Tom Lane | 2004-12-19 21:22:46 | Re: Shared row locking |