Re: FOR SHARE vs FOR UPDATE locks

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