On 08.06.2011 03:16, Kevin Grittner wrote:
+ /* + * It's OK to remove the old lock first because of the ACCESS + * EXCLUSIVE lock on the heap relation when this is called. It is + * desirable to do so because it avoids any chance of running out + * of lock structure entries for the table. + */
That assumption is wrong, for REINDEX. REINDEX INDEX holds an AccessExclusive on the index, but only a ShareLock on the heap. The code is still OK, though. As long as you hold an AccessExclusiveLock on the index, no-one will care about predicate locks on the index, so we can remove them before acquiring the lock on the heap. And we hold lwlocks on all the predicate lock partitions, so all the operations will appear atomic to any outside observer anyway.
Committed after adjusting that comment. I did a lot of other cosmetic changes too, please double-check that I didn't screw up anything.
I also made rewriting ALTER TABLE to behave like CLUSTER, by adding a call to TransferPredicateLocksToHeapRelation() there. I just looked back at your old email where you listed the different DDL operations, and notice that we missed VACUUM FULL as well (http://archives.postgresql.org/message-id/4dbd7e91020000250003d...@gw.wicourts.gov). I'll look into that. ALTER INDEX was also still an open question in that email.
BTW, truncating the tail of a heap in vacuum probably also should drop any locks on the truncated part of the heap. Or is it not possible any such locks to exist, because none of the tuples are visible to anyone anymore? A comment in lazy_truncate_heap() might be in order.
-- 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
