Re: SSI heap_insert and page-level predicate locks
От | Dan Ports |
---|---|
Тема | Re: SSI heap_insert and page-level predicate locks |
Дата | |
Msg-id | 20110608093657.GG26076@csail.mit.edu обсуждение исходный текст |
Ответ на | SSI heap_insert and page-level predicate locks (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: SSI heap_insert and page-level predicate locks
Re: SSI heap_insert and page-level predicate locks |
Список | pgsql-hackers |
On Wed, Jun 08, 2011 at 11:23:48AM +0300, Heikki Linnakangas wrote: > AFAICS, the check for page lock is actually unnecessary. A page-level > lock on a heap only occurs when tuple-level locks are promoted. It is > just a coarser-grain representation of holding locks on all tuples on > the page, *that exist already*. It is not a "gap" lock like the index > locks are, it doesn't need to conflict with inserting new tuples on the > page. In fact, if heap_insert chose to insert the tuple on some other > heap page, there would have been no conflict. Yes, it's certainly unnecessary now, given that we never explicitly take heap page locks, just tuple- or relation-level. The only thing I'd be worried about is that at some future point we might add heap page locks -- say, for sequential scans that don't read the entire relation -- and expect inserts to be tested against them. I'm not sure whether we'd actually do this, but we wanted to keep the option open during development. Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/
В списке pgsql-hackers по дате отправления: