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/4DBD7E91020000250003D0D6@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
