Assign AccessExclusiveLocks against subxacts in Hot Standby

Previously AELs were registered against the top-level xid, which could
cause locks to be held much longer than necessary in some cases during
Hot Standby replay. We now record locks directly against their appropriate
xids. Requires few code changes because original code allowed for this
situation but didn’t fully implement it.

Discussion: CAKJS1f9vJ841HY=wonnLVbfkTWGYWdPN72VMxnArcGCjF3SywA@mail.gmail.com

Author: Simon Riggs and David Rowley

diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index 7be8fd4a784b416556f60ece33e823e35931ac9c..8e57f933cab3ccdec4233e27eac4eec672d0c7b5 100644 (file)
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -590,10 +590,6 @@ StandbyLockTimeoutHandler(void)
  * RelationLockList, so we can keep track of the various entries made by
  * the Startup process's virtual xid in the shared lock table.
  *
- * We record the lock against the top-level xid, rather than individual
- * subtransaction xids. This means AccessExclusiveLocks held by aborted
- * subtransactions are not released as early as possible on standbys.
- *
  * List elements use type xl_rel_lock, since the WAL record type exactly
  * matches the information that we need to keep track of.
  *
@@ -1052,7 +1048,7 @@ LogAccessExclusiveLock(Oid dbOid, Oid relOid)
 {
    xl_standby_lock xlrec;
 
-   xlrec.xid = GetTopTransactionId();
+   xlrec.xid = GetCurrentTransactionId();
 
    /*
     * Decode the locktag back to the original values, to avoid sending lots
@@ -1084,7 +1080,7 @@ LogAccessExclusiveLockPrepare(void)
     * GetRunningTransactionLocks() might see a lock associated with an
     * InvalidTransactionId which we later assert cannot happen.
     */
-   (void) GetTopTransactionId();
+   (void) GetCurrentTransactionId();
 }
 
 /*