Re: FOR SHARE vs FOR UPDATE locks

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: FOR SHARE vs FOR UPDATE locks
Дата
Msg-id 457019C4.2030906@enterprisedb.com
обсуждение исходный текст
Ответ на Re: FOR SHARE vs FOR UPDATE locks  (Alvaro Herrera <alvherre@commandprompt.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: FOR SHARE vs FOR UPDATE locks
Следующее
От: Dave Cramer
Дата:
Сообщение: small pg_dump RFE: new --no-prompt (password) option