Re: FOR SHARE vs FOR UPDATE locks - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: FOR SHARE vs FOR UPDATE locks
Date
Msg-id 457019C4.2030906@enterprisedb.com
Whole thread Raw
In response to Re: FOR SHARE vs FOR UPDATE locks  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: FOR SHARE vs FOR UPDATE locks
Next
From: Dave Cramer
Date:
Subject: small pg_dump RFE: new --no-prompt (password) option