"Kevin Grittner" wrote:
> Heikki Linnakangas wrote:
>
>> I think the logic is actually wrong at the moment: When you
>> reindex a single index, DropAllPredicateLocksFromTableImpl() will
>> transfer all locks belonging to any index on the same table, and
>> any finer-granularity locks on the heap. It would be enough to
>> transfer only locks on the index being reindexed, so you risk
>> getting some unnecessary false positives.
>
> It seemed like a good idea at the time -- a relation lock on the
> heap makes any other locks on the heap or any of its indexes
> redundant. So it was an attempt at "cleaning house". Since we
> don't do anything for an index request unless there is a lock on
> that index, it couldn't cause false positives. But this probably
> fits into the category of premature optimizations, since the locks
> can't cause any difference in when you get a serialization failure
> -- it's only a matter of "taking up space". I could revert that.
On reflection, Heikki was dead-on right here; I had some fuzzy
thinking going. Just because one transaction has a lock in the index
doesn't mean that all transactions need lock promotion. That still
leaves an opportunity for cleanup, but it's much narrower -- only
locks from transactions which held locks on the reorganized index can
be replaced by the heap relation lock. That one is narrow enough to
be very unlikely to be worthwhile.
As usual, Heikki was right on target. :-)
-Kevin