mirror of
https://github.com/neondatabase/neon.git
synced 2026-01-13 08:22:55 +00:00
45f5dfc685
The bug described in - https://github.com/neondatabase/neon/issues/12168 is not covered by `test_hot_standby_gc[pause_apply=True]`. The reason is that the first standby reply _does_ trigger an update of the aggregate, but subsequent standby replies don't. Only hot_standby_feedback messaages do. In the test, that first reply sets standby_horizon to a low value X, thereby inhibiting gc, thereby making the test pass. However, the aggregate standby_horizon pushed by SKs remains at that low value X from here on. Actually, uh oh, this means standby_horizon is _kept_ at X!? And thus, if the PS receives re-push of low value X before the next GC, it will continue to limit GC to below X, until we hit the hard-coded `MAX_ALLOWED_STANDBY_LAG`. This is worse than I thought: it means that the current code _is_ preventing GC _even_ for standbys _without_ `hot_standby_feedback`, if those standbys shut down before 10GiB of WAL has been written since they were launched. Turn some debug logging into info logging to make the case. Sigh. refs - https://github.com/neondatabase/neon/issues/12168