postgres.git / summary / log / commit / refs

commit    03ccc9569cd87fcbe01e4ba052c22ad0d9a3b71d
Author:   Andres Freund <andres@anarazel.de>
Date:     Thu Jul 13 20:03:30 2023 +0000
First released in: 17.0, 11.21, 12.16, 13.12, 14.9, 15.4, 16.0

    Release lock after encountering bogs row in vac_truncate_clog()
    
    When vac_truncate_clog() encounters bogus datfrozenxid / datminmxid values, it
    returns early. Unfortunately, until now, it did not release
    WrapLimitsVacuumLock. If the backend later tries to acquire
    WrapLimitsVacuumLock, the session / autovacuum worker hangs in an
    uncancellable way. Similarly, other sessions will hang waiting for the
    lock. However, if the backend holding the lock exited or errored out for some
    reason, the lock was released.
    
    The bug was introduced as a side effect of 566372b3d643.
    
    It is interesting that there are no production reports of this problem. That
    is likely due to a mix of bugs leading to bogus values having gotten less
    common, process exit releasing locks and instances of hangs being hard to
    debug for "normal" users.
    
    Discussion: https://postgr.es/m/20230621221208.vhsqgduwfpzwxnpg@awork3.anarazel.de


 src/backend/commands/vacuum.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c
index 57ca41add2f..841188f71c0 100644
--- a/src/backend/commands/vacuum.c
+++ b/src/backend/commands/vacuum.c
@@ -1893,12 +1893,16 @@ vac_truncate_clog(TransactionId frozenXID,
 		ereport(WARNING,
 				(errmsg("some databases have not been vacuumed in over 2 billion transactions"),
 				 errdetail("You might have already suffered transaction-wraparound data loss.")));
+		LWLockRelease(WrapLimitsVacuumLock);
 		return;
 	}
 
 	/* chicken out if data is bogus in any other way */
 	if (bogus)
+	{
+		LWLockRelease(WrapLimitsVacuumLock);
 		return;
+	}
 
 	/*
 	 * Advance the oldest value for commit timestamps before truncating, so


[parent: e27f3f52c289]