Create VXID locks "lazily" in the main lock table.
authorRobert Haas <rhaas@postgresql.org>
Tue, 4 Oct 2011 16:37:26 +0000 (12:37 -0400)
committerRobert Haas <rhaas@postgresql.org>
Fri, 1 Jun 2012 12:29:52 +0000 (08:29 -0400)
commit12917f92364cd9ce41bee400c2875948851c8ca0
tree3a9e8b074922c40672d36f49aed4b2e708ce5d23
parent72bfe6221b23982044038d461698b1939948ce5a
Create VXID locks "lazily" in the main lock table.

Instead of entering them on transaction startup, we materialize them
only when someone wants to wait, which will occur only during CREATE
INDEX CONCURRENTLY.  In Hot Standby mode, the startup process must also
be able to probe for conflicting VXID locks, but the lock need never be
fully materialized, because the startup process does not use the normal
lock wait mechanism.  Since most VXID locks never need to touch the
lock manager partition locks, this can significantly reduce blocking
contention on read-heavy workloads.

Patch by me.  Review by Jeff Davis.

Conflicts:

src/backend/storage/lmgr/lock.c
src/backend/commands/indexcmds.c
src/backend/postmaster/autovacuum.c
src/backend/storage/ipc/sinvaladt.c
src/backend/storage/ipc/standby.c
src/backend/storage/lmgr/README
src/backend/storage/lmgr/lmgr.c
src/backend/storage/lmgr/lock.c
src/include/storage/lmgr.h
src/include/storage/lock.h
src/include/storage/proc.h
src/include/storage/sinvaladt.h