Re: Shared row locking

From: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>, Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Shared row locking
Date: 2004-12-21 21:48:52
Message-ID: 20041221214851.GM18180@decibel.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 20, 2004 at 03:09:24PM -0300, Alvaro Herrera wrote:
> To solve the problem I want to solve, we have three orthogonal
> possibilities:
>
> 1. implement shared row locking using the ideas outlined in the mail
> starting this thread (pg_clog-like seems to be the winner, details TBD).
>
> 2. implement shared lock table spill-to-disk mechanism.
>
> 3. implement lock escalation.
>
>
> Some people seems to think 3 is better than 2. What do they think of 1?
>
>
> Some facts:
>
> - DB2 implements 3 and some people have problems with deadlocks.

FWIW, I have seen DB2 deadlock on a single row update statement in a
database with no one else connected. It was an issue with how they were
implementing repeatable read concurrency. What this indicates to me is
that they've got some 'issues' with their locking mechanisms, and that
#3 shouldn't be thrown out just because DB2 doesn't do it right. AFAIK
Sybase and SQL-server also use lock escalation and I've not heard of
issues with it.
--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)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?"

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-12-21 22:01:04 Re: plperl: memory usage stacking
Previous Message Andrew Dunstan 2004-12-21 21:42:50 Re: plperl: memory usage stacking