aboutsummaryrefslogtreecommitdiff
path: root/src/tutorial/advanced.source
diff options
context:
space:
mode:
authorAndres Freund <andres@anarazel.de>2023-07-13 13:03:33 -0700
committerAndres Freund <andres@anarazel.de>2023-07-13 13:03:33 -0700
commite246fd42363fcfd61cb98fb338c307e52747973f (patch)
treee2a283805bd4c89f09bd6cbb153933e9dbf1bb76 /src/tutorial/advanced.source
parenta6991f763df8d2125ba2d53ef241bcdc6afc26cf (diff)
downloadpostgresql-e246fd42363fcfd61cb98fb338c307e52747973f.tar.gz
postgresql-e246fd42363fcfd61cb98fb338c307e52747973f.zip
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
Diffstat (limited to 'src/tutorial/advanced.source')
0 files changed, 0 insertions, 0 deletions