Re: FOR SHARE vs FOR UPDATE locks
От | Jim Nasby |
---|---|
Тема | Re: FOR SHARE vs FOR UPDATE locks |
Дата | |
Msg-id | C75C7EDB-65C0-4C5F-8981-9B2E94FBC004@decibel.org обсуждение исходный текст |
Ответ на | Re: FOR SHARE vs FOR UPDATE locks (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: FOR SHARE vs FOR UPDATE locks
|
Список | pgsql-hackers |
On Dec 1, 2006, at 10:46 AM, Tom Lane wrote: > If we > do make it throw an error I'm afraid that we will break applications > that aren't having a problem at the moment. What about throwing a warning? Shouldn't break anything, but at least then anyone who's experiencing this and has just gotten lucky so far will have a better idea that it's happening. As for possibly using the in-memory store of multiple CIDs affecting a tuple, could that not work if that store contained enough information to 'rollback' the lock to it's original state when restoring to a savepoint? AFAIK other backends would only need to know what the current lock being held was, they wouldn't need to know the history of it themselves... -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
В списке pgsql-hackers по дате отправления: