Skip site navigation (1) Skip section navigation (2)

[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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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: multixact.h
Description: text/x-chdr (1.0 KB)
Attachment: multixact.c
Description: text/x-csrc (27.1 KB)

Responses

pgsql-hackers by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group