Re: AW: AW: Issue NOTICE for attempt to raise lock leve l?
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: AW: AW: Issue NOTICE for attempt to raise lock leve l? |
| Дата | |
| Msg-id | 17142.973630939@sss.pgh.pa.us обсуждение |
| Ответ на | RE: AW: AW: Issue NOTICE for attempt to raise lock leve l? ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>) |
| Список | pgsql-hackers |
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> Unfortunately, session 3 with just SELECT * FROM foo will also wait
> for session 1 & session 2 commit.
Session 3 would wait for session 2 in any case, no?
This is all irrelevant unless someone can make a convincing case that
it's safe to release read locks early. In the words of the ancient
sage, "I can make this program arbitrarily fast ... if it doesn't have
to give the right answer". I have already pointed out several cases
where releasing locks early is clearly *not* safe. I don't think I
need to produce more examples. The burden of proof is on the other
side to show how it can be done safely (and with an amount of work
that's reasonable for 7.1, which is not too darn much at this point).
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера