rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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 566372b3d6.

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
This commit is contained in:
Andres Freund 2023-07-13 13:03:30 -07:00
parent e27f3f52c2
commit 03ccc9569c
1 changed files with 4 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
src/backend/commands/vacuum.c
View File

@ -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