pgsql: Release lock after encountering bogs row in vac_truncate_clog()
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.vhsqgduwfpzwx...@awork3.anarazel.de Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/03ccc9569cd87fcbe01e4ba052c22ad0d9a3b71d Modified Files -- src/backend/commands/vacuum.c | 4 1 file changed, 4 insertions(+)
pgsql: Release lock after encountering bogs row in vac_truncate_clog()
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.vhsqgduwfpzwx...@awork3.anarazel.de Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/82e97b864004810db2d335cf26117f7f1c2ff435 Modified Files -- src/backend/commands/vacuum.c | 4 1 file changed, 4 insertions(+)
pgsql: Release lock after encountering bogs row in vac_truncate_clog()
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.vhsqgduwfpzwx...@awork3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/83ecfa9fad11448af2cbac6c9f2a03507e6317cf Modified Files -- src/backend/commands/vacuum.c | 4 1 file changed, 4 insertions(+)
pgsql: Release lock after encountering bogs row in vac_truncate_clog()
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.vhsqgduwfpzwx...@awork3.anarazel.de Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e246fd42363fcfd61cb98fb338c307e52747973f Modified Files -- src/backend/commands/vacuum.c | 4 1 file changed, 4 insertions(+)
pgsql: Release lock after encountering bogs row in vac_truncate_clog()
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.vhsqgduwfpzwx...@awork3.anarazel.de Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7aec84e4c2652d9928916330f612de21e40621d8 Modified Files -- src/backend/commands/vacuum.c | 4 1 file changed, 4 insertions(+)
pgsql: Release lock after encountering bogs row in vac_truncate_clog()
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.vhsqgduwfpzwx...@awork3.anarazel.de Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1386f09871a14a8658d924df18a31ddf595e8345 Modified Files -- src/backend/commands/vacuum.c | 4 1 file changed, 4 insertions(+)
pgsql: Release lock after encountering bogs row in vac_truncate_clog()
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.vhsqgduwfpzwx...@awork3.anarazel.de Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/53336e8f6675c30e35e85f87993d9df0db7e1cb0 Modified Files -- src/backend/commands/vacuum.c | 4 1 file changed, 4 insertions(+)
