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
