Skip to content

Commit 84e3712

Browse files
robertmhaasrobertmhaas
committed
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.
1 parent 3b17efd commit 84e3712

File tree

11 files changed

+257
-95
lines changed

11 files changed

+257
-95
lines changed

‎src/backend/commands/indexcmds.c

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -683,7 +683,7 @@ DefineIndex(RangeVar *heapRelation,
683683

684684
while (VirtualTransactionIdIsValid(*old_lockholders))
685685
{
686-
VirtualXactLockTableWait(*old_lockholders);
686+
VirtualXactLock(*old_lockholders, true);
687687
old_lockholders++;
688688
}
689689

@@ -769,7 +769,7 @@ DefineIndex(RangeVar *heapRelation,
769769

770770
while (VirtualTransactionIdIsValid(*old_lockholders))
771771
{
772-
VirtualXactLockTableWait(*old_lockholders);
772+
VirtualXactLock(*old_lockholders, true);
773773
old_lockholders++;
774774
}
775775

@@ -866,7 +866,7 @@ DefineIndex(RangeVar *heapRelation,
866866
}
867867

868868
if (VirtualTransactionIdIsValid(old_snapshots[i]))
869-
VirtualXactLockTableWait(old_snapshots[i]);
869+
VirtualXactLock(old_snapshots[i], true);
870870
}
871871

872872
/*

‎src/backend/postmaster/autovacuum.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1992,7 +1992,7 @@ do_autovacuum(void)
19921992
backendID = GetTempNamespaceBackendId(classForm->relnamespace);
19931993

19941994
/* We just ignore it if the owning backend is still active */
1995-
if (backendID == MyBackendId || !BackendIdIsActive(backendID))
1995+
if (backendID == MyBackendId || BackendIdGetProc(backendID) == NULL)
19961996
{
19971997
/*
19981998
* We found an orphan temp table (which was probably left

‎src/backend/storage/ipc/sinvaladt.c

Lines changed: 13 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -139,6 +139,7 @@ typedef struct ProcState
139139
{
140140
/* procPid is zero in an inactive ProcState array entry. */
141141
pid_t procPid; /* PID of backend, for signaling */
142+
PGPROC *proc; /* PGPROC of backend */
142143
/* nextMsgNum is meaningless if procPid == 0 or resetState is true. */
143144
int nextMsgNum; /* next message number to read */
144145
bool resetState; /* backend needs to reset its state */
@@ -246,6 +247,7 @@ CreateSharedInvalidationState(void)
246247
for (i = 0; i < shmInvalBuffer->maxBackends; i++)
247248
{
248249
shmInvalBuffer->procState[i].procPid = 0; /* inactive */
250+
shmInvalBuffer->procState[i].proc = NULL;
249251
shmInvalBuffer->procState[i].nextMsgNum = 0; /* meaningless */
250252
shmInvalBuffer->procState[i].resetState = false;
251253
shmInvalBuffer->procState[i].signaled = false;
@@ -313,6 +315,7 @@ SharedInvalBackendInit(bool sendOnly)
313315

314316
/* mark myself active, with all extant messages already read */
315317
stateP->procPid = MyProcPid;
318+
stateP->proc = MyProc;
316319
stateP->nextMsgNum = segP->maxMsgNum;
317320
stateP->resetState = false;
318321
stateP->signaled = false;
@@ -353,6 +356,7 @@ CleanupInvalidationState(int status, Datum arg)
353356

354357
/* Mark myself inactive */
355358
stateP->procPid = 0;
359+
stateP->proc = NULL;
356360
stateP->nextMsgNum = 0;
357361
stateP->resetState = false;
358362
stateP->signaled = false;
@@ -369,13 +373,16 @@ CleanupInvalidationState(int status, Datum arg)
369373
}
370374

371375
/*
372-
* BackendIdIsActive
373-
* Test if the given backend ID is currently assigned to a process.
376+
* BackendIdGetProc
377+
* Get the PGPROC structure for a backend, given the backend ID.
378+
* The result may be out of date arbitrarily quickly, so the caller
379+
* must be careful about how this information is used. NULL is
380+
* returned if the backend is not active.
374381
*/
375-
bool
376-
BackendIdIsActive(int backendID)
382+
PGPROC *
383+
BackendIdGetProc(int backendID)
377384
{
378-
bool result;
385+
PGPROC *result = NULL;
379386
SISeg *segP = shmInvalBuffer;
380387

381388
/* Need to lock out additions/removals of backends */
@@ -385,10 +392,8 @@ BackendIdIsActive(int backendID)
385392
{
386393
ProcState *stateP = &segP->procState[backendID - 1];
387394

388-
result = (stateP->procPid != 0);
395+
result = stateP->proc;
389396
}
390-
else
391-
result = false;
392397

393398
LWLockRelease(SInvalWriteLock);
394399

‎src/backend/storage/ipc/standby.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -201,7 +201,7 @@ ResolveRecoveryConflictWithVirtualXIDs(VirtualTransactionId *waitlist,
201201
standbyWait_us = STANDBY_INITIAL_WAIT_US;
202202

203203
/* wait until the virtual xid is gone */
204-
while (!ConditionalVirtualXactLockTableWait(*waitlist))
204+
while (!VirtualXactLock(*waitlist, false))
205205
{
206206
/*
207207
* Report via ps if we have been waiting for more than 500 msec

‎src/backend/storage/lmgr/README

Lines changed: 30 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -263,16 +263,23 @@ Fast Path Locking
263263
-----------------
264264

265265
Fast path locking is a special purpose mechanism designed to reduce the
266-
overhead of taking and releasing weak relation locks. SELECT, INSERT,
267-
UPDATE, and DELETE must acquire a lock on every relation they operate on,
268-
as well as various system catalogs that can be used internally. These locks
269-
are notable not only for the very high frequency with which they are taken
270-
and released, but also for the fact that they virtually never conflict.
271-
Many DML operations can proceed in parallel against the same table at the
272-
same time; only DDL operations such as CLUSTER, ALTER TABLE, or DROP -- or
273-
explicit user action such as LOCK TABLE -- will create lock conflicts with
274-
the "weak" locks (AccessShareLock, RowShareLock, RowExclusiveLock) acquired
275-
by DML operations.
266+
overhead of taking and releasing certain types of locks which are taken
267+
and released very frequently but rarely conflict. Currently, this includes
268+
two categories of locks:
269+
270+
(1) Weak relation locks. SELECT, INSERT, UPDATE, and DELETE must acquire a
271+
lock on every relation they operate on, as well as various system catalogs
272+
that can be used internally. Many DML operations can proceed in parallel
273+
against the same table at the same time; only DDL operations such as
274+
CLUSTER, ALTER TABLE, or DROP -- or explicit user action such as LOCK TABLE
275+
-- will create lock conflicts with the "weak" locks (AccessShareLock,
276+
RowShareLock, RowExclusiveLock) acquired by DML operations.
277+
278+
(2) VXID locks. Every transaction takes a lock on its own virtual
279+
transaction ID. Currently, the only operations that wait for these locks
280+
are CREATE INDEX CONCURRENTLY and Hot Standby (in the case of a conflict),
281+
so most VXID locks are taken and released by the owner without anyone else
282+
needing to care.
276283

277284
The primary locking mechanism does not cope well with this workload. Even
278285
though the lock manager locks are partitioned, the locktag for any given
@@ -284,8 +291,8 @@ even on 2-core servers, and becomes very pronounced as core count increases.
284291
To alleviate this bottleneck, beginning in PostgreSQL 9.2, each backend is
285292
permitted to record a limited number of locks on unshared relations in an
286293
array within its PGPROC structure, rather than using the primary lock table.
287-
This is called the "fast path" mechanism, and can only be used when the
288-
locker can verify that no conflicting locks can possibly exist.
294+
This mechanism can only be used when the locker can verify that no conflicting
295+
locks can possibly exist.
289296

290297
A key point of this algorithm is that it must be possible to verify the
291298
absence of possibly conflicting locks without fighting over a shared LWLock or
@@ -317,6 +324,17 @@ the strong locker has yet to acquire the per-backend LWLock we now hold (or,
317324
indeed, even the first per-backend LWLock) and will notice any weak lock we
318325
take when it does.
319326

327+
Fast-path VXID locks do not use the FastPathStrongLocks table. The first
328+
lock taken on a VXID is always the ExclusiveLock taken by its owner. Any
329+
subsequent lockers are share lockers waiting for the VXID to terminate.
330+
Indeed, the only reason VXID locks use the lock manager at all (rather than
331+
waiting for the VXID to terminate via some other method) is for deadlock
332+
detection. Thus, the initial VXID lock can *always* be taken via the fast
333+
path without checking for conflicts. Any subsequent locker must check
334+
whether the lock has been transferred to the main lock table, and if not,
335+
do so. The backend owning the VXID must be careful to clean up any entry
336+
made in the main lock table at end of transaction.
337+
320338

321339
The Deadlock Detection Algorithm
322340
--------------------------------

‎src/backend/storage/lmgr/lmgr.c

Lines changed: 0 additions & 64 deletions
Original file line numberDiff line numberDiff line change
@@ -515,70 +515,6 @@ ConditionalXactLockTableWait(TransactionId xid)
515515
return true;
516516
}
517517

518-
519-
/*
520-
* VirtualXactLockTableInsert
521-
*
522-
* Insert a lock showing that the given virtual transaction ID is running ---
523-
* this is done at main transaction start when its VXID is assigned.
524-
* The lock can then be used to wait for the transaction to finish.
525-
*/
526-
void
527-
VirtualXactLockTableInsert(VirtualTransactionId vxid)
528-
{
529-
LOCKTAG tag;
530-
531-
Assert(VirtualTransactionIdIsValid(vxid));
532-
533-
SET_LOCKTAG_VIRTUALTRANSACTION(tag, vxid);
534-
535-
(void) LockAcquire(&tag, ExclusiveLock, false, false);
536-
}
537-
538-
/*
539-
* VirtualXactLockTableWait
540-
*
541-
* Waits until the lock on the given VXID is released, which shows that
542-
* the top-level transaction owning the VXID has ended.
543-
*/
544-
void
545-
VirtualXactLockTableWait(VirtualTransactionId vxid)
546-
{
547-
LOCKTAG tag;
548-
549-
Assert(VirtualTransactionIdIsValid(vxid));
550-
551-
SET_LOCKTAG_VIRTUALTRANSACTION(tag, vxid);
552-
553-
(void) LockAcquire(&tag, ShareLock, false, false);
554-
555-
LockRelease(&tag, ShareLock, false);
556-
}
557-
558-
/*
559-
* ConditionalVirtualXactLockTableWait
560-
*
561-
* As above, but only lock if we can get the lock without blocking.
562-
* Returns TRUE if the lock was acquired.
563-
*/
564-
bool
565-
ConditionalVirtualXactLockTableWait(VirtualTransactionId vxid)
566-
{
567-
LOCKTAG tag;
568-
569-
Assert(VirtualTransactionIdIsValid(vxid));
570-
571-
SET_LOCKTAG_VIRTUALTRANSACTION(tag, vxid);
572-
573-
if (LockAcquire(&tag, ShareLock, false, true) == LOCKACQUIRE_NOT_AVAIL)
574-
return false;
575-
576-
LockRelease(&tag, ShareLock, false);
577-
578-
return true;
579-
}
580-
581-
582518
/*
583519
* LockDatabaseObject
584520
*

0 commit comments

Comments
 (0)