| От | Daniel Farina |
|---|---|
| Тема | Re: questions about concurrency control in Postgresql |
| Дата | |
| Msg-id | 7b97c5a40912072201h6575201eid6597fc42052dd18@mail.gmail.com обсуждение |
| Ответ на | questions about concurrency control in Postgresql (黄晓骋 <huangxclife@gmail.com>) |
| Список | pgsql-hackers |
2009/12/7 黄晓骋 <huangxclife@gmail.com>: > Hello, > > I think in Postgresql, concurrency control acts like this: > > tuple's infomask shows if it is being updated. If it is being updated now, > the latter transaction should reread the tuple and get the newer tuple. > During the progress of getting the newer tuple, it must use transaction > lock, I mean XactLockTableWait(...). That is a table lock...depending on the lock, other backends may be allowed to update tuples in the relation still. Fine-grained tuple locks are used to prevent unnecessary contention for a table-wide lock. See the documentation at the manual page: http://www.postgresql.org/docs/8.4/static/explicit-locking.html It gives a thorough treatment of table and row locking levels and conflicts, as well as what gets what locks. fdr
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера