thread-index: AccVQI2Sz3+yy+AFRQKjVeN0+Z1BZA==
Message-ID: <457019C4.2030906@enterprisedb.com>
Content-Class: urn:content-classes:message
Importance: normal
Date: Fri, 01 Dec 2006 12:02:12 +0000
From: "Heikki Linnakangas" <heikki@enterprisedb.com>
User-Agent: Thunderbird 1.5.0.7 (X11/20060927)
MIME-Version: 1.0
To: "Simon Riggs" <simon@2ndquadrant.com>, "Tom Lane" <tgl@sss.pgh.pa.us>,
	<pgsql-hackers@postgreSQL.org>
Subject: Re: FOR SHARE vs FOR UPDATE locks
References: <1144.1164924373@sss.pgh.pa.us>
	<1164962544.3778.847.camel@silverbirch.site>
	<20061201113711.GC30441@alvh.no-ip.org>
In-Reply-To: <20061201113711.GC30441@alvh.no-ip.org>
Content-Type: text/plain;
	format=flowed;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Alvaro Herrera wrote:
> Simon Riggs wrote:
> 
>> ISTM that multitrans could be used here. Two xids, one xmax.
> 
> Hmm, yeah, this seems a reasonable suggestion.  The problem is that we
> don't have a mechanism today for saying "this Xid holds a shared lock,
> this one holds an exclusive lock".  So code-wise it wouldn't be simple
> to do.  It's a single bit per Xid, but I don't see where to store such a
> thing.

We could store an extra byte in front of each xid in the multixact 
member file. That would screw up alignment, though, unless we pad it up 
to int32, but that would double the space taken by the members file.

Could we make the combination HEAP_XMAX_EXCL_LOCK | HEAP_XMAX_IS_MULTI 
legal, with the meaning that the last member in the multixact is an 
exclusive locker, if it's still in-progress?

> I'm not sure we can use the simple "raise an ERROR" answer though,
> because for users that would be a regression.

Yeah, that's ugly. Though it doesn't behave correctly as it is either...

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com