Technical Analysis: Removing Autoanalyze Corner Case in Anti-Wraparound Vacuum

The Core Problem

PostgreSQL's autovacuum system has a subtle and likely unintentional behavioral corner case related to anti-wraparound vacuum operations and autoanalyze. When autovacuum is disabled via the per-table autovacuum_enabled reloption (but not disabled via the global autovacuum or track_counts GUCs), anti-wraparound autovacuum still runs (by design — wraparound protection must not be defeatable). However, in this specific configuration, an autoanalyze is also triggered alongside the anti-wraparound vacuum.

Why This Matters Architecturally

1. No logical correlation: Anti-wraparound vacuum is triggered by transaction ID age thresholds (autovacuum_freeze_max_age), which has absolutely no correlation with statistical changes in table data. ANALYZE exists to update planner statistics when data distribution changes. A near-miss on wraparound tells you nothing about whether your statistics are stale.

2. Inconsistent behavior: The behavior only manifests in one specific configuration path (reloption-disabled but GUC-enabled). When autovacuum is disabled via the autovacuum GUC, this spurious analyze does NOT happen. Two configurations that are "supposed to behave the same way" (per Robert Treat's observation) behave differently.

3. Violation of user intent: A DBA who sets autovacuum_enabled = false on a table is explicitly saying "I don't want automatic maintenance on this table" (with the understood exception of wraparound prevention). Silently running ANALYZE contradicts that intent.

The Fix

The patch is straightforward: remove the code path that triggers autoanalyze when anti-wraparound autovacuum fires on tables with the autovacuum_enabled reloption set to false. This is a simple removal of a conditional branch in the autovacuum worker logic (likely in src/backend/postmaster/autovacuum.c).

The code in question would have been in the section that determines whether to perform analyze after a vacuum operation, where the anti-wraparound path was incorrectly allowing analyze to proceed even when the table had opted out of autovacuum via reloptions.

Design Decisions and Tradeoffs

• No backport concern: Since this is clearly unintentional behavior that nobody has relied upon (no documentation, no mention in archives), removing it poses minimal risk.
• Documentation question: Shinya Kato proposed adding explicit documentation stating that anti-wraparound autovacuum does NOT perform ANALYZE. This makes the (now corrected) behavior explicit for users who might wonder about the interaction.
• Commit scope: Nathan Bossart chose to commit just the behavioral fix without the documentation updates, keeping the commit minimal and focused. The documentation patch was offered as a follow-up.

Technical Context

The autovacuum system has two distinct "force" mechanisms:

• Anti-wraparound vacuum: Cannot be disabled by any means (by design, to prevent data loss from XID wraparound)
• Regular autovacuum + autoanalyze: Can be disabled per-table or globally

The bug existed at the intersection of these mechanisms — the anti-wraparound path was "leaking" an analyze operation that should have been gated by the same disable checks that govern regular autoanalyze.

Consensus

This thread shows unusually rapid and unanimous consensus. Four experienced contributors (+1'd within ~24 hours), the patch was reviewed and deemed correct, and it was committed within 2 days of the initial proposal. This speed reflects the clarity of the bug and the simplicity of the fix.