Re: SIREAD lock versus ACCESS EXCLUSIVE lock
От | Heikki Linnakangas |
---|---|
Тема | Re: SIREAD lock versus ACCESS EXCLUSIVE lock |
Дата | |
Msg-id | 4DEE672A.2030109@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: SIREAD lock versus ACCESS EXCLUSIVE lock ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: SIREAD lock versus ACCESS EXCLUSIVE lock
|
Список | pgsql-hackers |
On 07.06.2011 20:42, Kevin Grittner wrote: > Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> wrote: > >> It makes me a bit uncomfortable to do catalog cache lookups while >> holding all the lwlocks. > > I think I've caught up with the rest of the class on why this isn't > sane in DropAllPredicateLocksFromTableImpl, but I wonder about > CheckTableForSerializableConflictIn. We *do* expect to be throwing > errors in here, and we need some way to tell whether an index is > associated with a particular heap relation. Is the catalog cache > the right way to check that here, or is something else more > appropriate? Hmm, it's not as dangerous there, as you're not in the middle of modifying stuff, but it doesn't feel right there either. Predicate locks on indexes are only needed to lock key ranges, to notice later insertions into the range, right? For locks on tuples that do exist, we have locks on the heap. If we're just about to delete every tuple in the heap, that doesn't need to conflict with any locks on indexes, because we're deleting, not inserting. So I don't think we need to care about index locks here at all, only locks on the heap. Am I missing something? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: