| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Signed-off-by: bt90 <btom1990@googlemail.com>
|
Good direction with splitting incremental_vacuum into bounded chunks. However, as #10559 suggests checkpoint starvation is caused by frequent readers rather than simply excess freelist growth, is there a risk of tying checkpoint attempts too closely to vacuum triggering here? Also, if WAL growth happens independently of freelist thresholds (as it seems to), should checkpoint escalation (PASSIVE -> FULL/RESTART) be driven by WAL conditions rather than vacuum conditions? |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Purpose
Fixes #10554
Previously, we used to perform a full incremental vacuum run as part of our periodic clean-up. This is problematic for two reasons:
This PR causes vacuum to be skipped if the number of free pages is less than 1k or 10% of the database size. If the freelist exceeds this threshold, an incremental vacuum is invoked in a loop, with a limit of 1k pages per execution. To avoid uncontrolled WAL growth, a passive checkpoint is attempted every fourth invocation. If multiple passive checkpoints fail to complete, we switch to a restart checkpoint for the next iteration.
Testing
TBD
Authorship
Your name and email will be added automatically to the AUTHORS file
based on the commit metadata.