[WIP] shared locks

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Patches <pgsql-patches(at)postgresql(dot)org>
Subject: [WIP] shared locks
Date: 2005-04-18 23:22:53
Message-ID: 20050418232253.GA23483@surnet.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Hackers,

Here is another attempt at the shared locks patch. This is a radically
different approach, using Xmax in the tuples and SLRU areas instead of
the lock manager.

The idea is that a tuple's Xmax can either be a real TransactionId
(which is used normally like current CVS tip), or, if the infomask has
HEAP_XMAX_SHARED_LOCK, a MultiXactId.

A MultiXactId is an abstraction for a set of TransactionIds. So a
locker can sleep on the set (effectively calling XactLockTableWait on
each member), add itself to a previously existing set, or create a new
set with only itself.

MultiXactIds are implemented using two SLRU areas and a couple of
variables in ShmemVariableCache. We also XLog groups of them just like
we do for Oids.

This patch is a work in progress. I need to test it more, but the basic
infrastructure is written and working. I'd love some comments on the
basic design idea.

The patch applies cleanly to current CVS tip. There are two new files
which are src/backend/access/transam/multixact.c and
src/include/access/multixact.h, included separately.

Thanks,

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"I dream about dreams about dreams", sang the nightingale
under the pale moon (Sandman)

Attachment Content-Type Size
multixact.c text/x-csrc 27.1 KB
multixact.h text/x-chdr 1.0 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-04-19 00:00:57 Re: [WIP] shared locks
Previous Message Tom Lane 2005-04-18 23:21:59 Re: Problem with PITR recovery

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2005-04-19 00:00:57 Re: [WIP] shared locks
Previous Message Tom Lane 2005-04-18 05:42:06 Re: [PATCHES] Exception handling: Oracle's "SQLERRM" keyword option?