Received: from localhost (maia-4.hub.org [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id 1D52C9FA432
	for <pgsql-hackers-postgresql.org@postgresql.org>;
	Tue,  5 Dec 2006 12:03:57 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-new, port 10024)
	with ESMTP id 92476-01 for
	<pgsql-hackers-postgresql.org@postgresql.org>;
	Tue,  5 Dec 2006 12:03:44 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id C09309FA37A
	for <pgsql-hackers@postgresql.org>;
	Tue,  5 Dec 2006 12:03:43 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id kB5G3Xej005316;
	Tue, 5 Dec 2006 11:03:33 -0500 (EST)
To: Jim Nasby <decibel@decibel.org>
cc: "Heikki Linnakangas" <heikki@enterprisedb.com>,
	"Alvaro Herrera" <alvherre@commandprompt.com>,
	"Simon Riggs" <simon@2ndquadrant.com>, pgsql-hackers@postgresql.org
Subject: Re: FOR SHARE vs FOR UPDATE locks 
In-reply-to: <C75C7EDB-65C0-4C5F-8981-9B2E94FBC004@decibel.org> 
References: <1144.1164924373@sss.pgh.pa.us>
	<1164962544.3778.847.camel@silverbirch.site>
	<20061201113711.GC30441@alvh.no-ip.org>
	<15834.1164985926@sss.pgh.pa.us>
	<45705E9C.2060003@enterprisedb.com> <534.1164994846@sss.pgh.pa.us>
	<45706A77.8030503@enterprisedb.com> <1128.1164998817@sss.pgh.pa.us>
	<C75C7EDB-65C0-4C5F-8981-9B2E94FBC004@decibel.org>
Comments: In-reply-to Jim Nasby <decibel@decibel.org>
	message dated "Sun, 03 Dec 2006 22:44:01 -0800"
Date: Tue, 05 Dec 2006 11:03:33 -0500
Message-ID: <5315.1165334613@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200612/177
X-Sequence-Number: 94657

Jim Nasby <decibel@decibel.org> writes:
> As for possibly using the in-memory store of multiple CIDs affecting  
> a tuple, could that not work if that store contained enough  
> information to 'rollback' the lock to it's original state when  
> restoring to a savepoint? AFAIK other backends would only need to  
> know what the current lock being held was, they wouldn't need to know  
> the history of it themselves...

One of the interesting problems is that if you upgrade shared lock to
exclusive and then want to roll that back, you might need to un-block
other processes that tried to acquire share lock after you acquired
exclusive.  We have no way to do that in the current implementation.
(Any such processes will be blocked on your transaction ID lock, which
you can't release without possibly unblocking the wrong processes.)

			regards, tom lane