Re: Shared row locking - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: Shared row locking
Date
Msg-id 20041221214851.GM18180@decibel.org
Whole thread Raw
In response to Re: Shared row locking  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
List 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@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?"


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: plperl: memory usage stacking
Next
From: Tom Lane
Date:
Subject: Re: plperl: memory usage stacking