Re: FOR SHARE vs FOR UPDATE locks
От | Tom Lane |
---|---|
Тема | Re: FOR SHARE vs FOR UPDATE locks |
Дата | |
Msg-id | 15834.1164985926@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: FOR SHARE vs FOR UPDATE locks (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: FOR SHARE vs FOR UPDATE locks
Re: FOR SHARE vs FOR UPDATE locks |
Список | pgsql-hackers |
Alvaro Herrera <alvherre@commandprompt.com> writes: > I'm not sure we can use the simple "raise an ERROR" answer though, > because for users that would be a regression. I've reconsidered the idea of upgrading the outer xact's shared lock to exclusive: at first I thought that would be hard to implement correctly, but now I realize it's easy. Just re-use the XID that's in the multixact as the one to store as the exclusive locker, instead of storing our current subxact XID. In some cases this will be a subcommitted XID of the current subxact or a parent, but the locking semantics are the same, and even though we think such an XID is finished everyone else will see it as still live so the appearance of its XID in an XMAX field shouldn't be an issue. So that's what I propose doing. regards, tom lane
В списке pgsql-hackers по дате отправления: