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

Re: [WIP] shared locks

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [WIP] shared locks
Date: 2005-04-19 04:00:40
Message-ID: 20050419040040.GA6050@dcc.uchile.cl (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Mon, Apr 18, 2005 at 09:53:38PM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> > > 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.
> > 
> > Interesting idea.  Would it be possible to invoke this mechanism only
> > when actually needed --- that is, the first locker of a given tuple
> > puts his plain TransactionId into Xmax (and also sets an infomask bit
> > indicating his intent to have a shared rather than exclusive lock),
> > and then the second locker to come along replaces the TransactionId
> > with a MultiTransactionId including himself and the first locker?
> > 
> > This requires 2 infomask bits: 1 for shared vs exclusive lock and one
> > for whether the Xmax contains a TransactionId or MultiTransactionId.
> > But we have them available, and I think I like keeping those concepts
> > separate anyway.  (Who's to say we wouldn't want to allow a
> > MultiTransactionId to hold an exclusive lock, someday?)
> > 
> > The advantage of course would be substantially less overhead in the very
> > common case where there's no actual contention for the tuple.
> 
> Yes, that is certainly possible.  Alvaro felt he wanted something
> simpler and that the two-bit case would add complexity, but I agree it
> would reduce overhead in the most common case.

I had thought it would make things more complicated.  Now that I know
how the whole thing works I can handle the extra complexity, which is not
much really.  Also I wasn't sure if we wanted to waste two infomask
bits on this :-)

> > > 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.
> > 
> > So no need for expansible shmem storage?  Might be the way to go.

Right.  I have stashed some info (like next MultiXactId to assign, the
first MultiXactId this transaction was assigned, etc) in
ShmemVariableCache and PGPROC, but I'm now thinking in storing it
in a [fixed size] shmem area private to multixact.c; this way I don't
have to lock SInvalLock.

BTW, I had to use three additional LWLocks: two for SLRU and one for
MultiXactId generation, which also covers the ShmemVariableCache
variables.  I hope that's OK.

-- 
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
"No es bueno caminar con un hombre muerto"

In response to

pgsql-hackers by date

Next:From: Dinesh PandeyDate: 2005-04-19 04:04:41
Subject: Re: [HACKERS] Implementation of SQLCODE and SQLERRM variables
Previous:From: Bruce MomjianDate: 2005-04-19 03:59:13
Subject: Re: [HACKERS] Implementation of SQLCODE and SQLERRM variables

pgsql-patches by date

Next:From: Dinesh PandeyDate: 2005-04-19 04:04:41
Subject: Re: [HACKERS] Implementation of SQLCODE and SQLERRM variables
Previous:From: Bruce MomjianDate: 2005-04-19 03:59:13
Subject: Re: [HACKERS] Implementation of SQLCODE and SQLERRM variables

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