Fix potential corruption of lock table in CREATE/DROP INDEX CONCURRENTLY. If VirtualXactLock() has to wait for a transaction that holds its VXID lock as a fast-path lock, it must first convert the fast-path lock to a regular lock. It failed to take the required "partition" lock on the main shared-memory lock table while doing so. This is the direct cause of the assert failure in GetLockStatusData() recently observed in the buildfarm, but more worryingly it could result in arbitrary corruption of the shared lock table if some other process were concurrently engaged in modifying the same partition of the lock table. Fortunately, VirtualXactLock() is only used by CREATE INDEX CONCURRENTLY and DROP INDEX CONCURRENTLY, so the opportunities for failure are fewer than they might have been.
In passing, improve some comments and be a bit more consistent about order of operations. Branch ------ REL9_2_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/fe35c0b6e54d0787ccab17974010a48a8a3ba6d3 Modified Files -------------- src/backend/storage/lmgr/lock.c | 29 +++++++++++++++++++++++++---- 1 files changed, 25 insertions(+), 4 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
