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 |
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 |
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? |