On 07.06.2011 20:42, Kevin Grittner wrote:
Heikki Linnakangas<heikki.linnakan...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
