Re: Shared row locking

On Mon, Dec 20, 2004 at 11:47:41AM -0500, Tom Lane wrote:

> To me, "performance buster" is better than "random, unrepeatable
> deadlock failures". In any case, if we find we *can't* implement this
> in a non-performance-busting way, then it would be time enough to look
> at alternatives that force the user to manage the problem for us.

I am confused by this discussion.

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.

- 2 could have a performance impact, and we don't even know how to
start. For example, what would be an algorithm to decide what locks
to send to disk?

- I am interested in implementing 1, maybe 2. Don't know about 3.

--
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
One man's impedance mismatch is another man's layer of abstraction.
(Lincoln Yeoh)