public inbox for [email protected]  

help / color / mirror / Atom feed

From: Heikki Linnakangas <[email protected]>
To: Tom Lane <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Simon Riggs <[email protected]>
Cc: [email protected]
Subject: Re: FOR SHARE vs FOR UPDATE locks
Date: Fri, 01 Dec 2006 17:46:31 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

Tom Lane wrote:
> Actually ... wait a minute.  The proposed hack covers the case of
> SELECT FOR SHARE followed by SELECT FOR UPDATE within a subtransaction.
> But what about SELECT FOR SHARE followed by an actual UPDATE (or DELETE)?
> 
> We certainly don't want to mark the UPDATE/DELETE as having been carried
> out by the upper transaction, but there's no way we can record the
> UPDATE while still remembering the previous share-lock.
> 
> So I think I'm back to the position that we should throw an error here.

Yeah. Even without a real update, I just figured you can't upgrade a 
shared lock held by an arbitrarily chosen parent to an exclusive lock. 
If that subxid aborts, and if any of the parents of that subtransaction 
held the shared lock, that lock would be released incorrectly. Which is 
essentially the same problem we began with.

Let's throw an error for now. We have to come back to this in 8.3, I think.

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

view thread (32+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: FOR SHARE vs FOR UPDATE locks
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox