pageserver: use PITR GC cutoffs as authoritative

[jcsp]

Problem

Pageserver GC uses a size-based condition (GC "horizon" in addition to time-based "PITR").

Eventually we plan to retire the size-based condition: #6374

Currently, we always apply the more conservative of the two, meaning that tenants always retain at least 64MB of history (default horizon), even after a very long time has passed. This is particularly acute in cases where someone has dropped tables/databases, and then leaves a database idle: the horizon can prevent GCing very large quantities of historical data (we already account for this in synthetic size by ignoring gc horizon).

We're not entirely removing GC horizon right now because we don't want to 100% rely on standby_horizon for robustness of physical replication, but we can tweak our logic to avoid retaining that 64MB LSN length indefinitely.

Summary of changes

• Rework Timeline::find_gc_cutoffs, with new logic:
  • If there is no PITR set, then use DEFAULT_PITR_INTERVAL (1 week) to calculate a time threshold. Retain either the horizon or up to that thresholds, whichever requires less data.
  • When there is a PITR set, and we have unambiguously resolved the timestamp to an LSN, then ignore the GC horizon entirely. For typical PITRs (1 day, 1 week), this will still easily retain enough data to avoid stressing read only replicas.

The key property we end up with, whether a PITR is set or not, is that after enough time has passed, our GC cutoff on an idle timeline will catch up with the last_record_lsn.

Using DEFAULT_PITR_INTERVAL is a bit of an arbitrary hack, but this feels like it isn't really worth the noise of exposing in TenantConfig. We could just make it a different named constant though. The end-end state will be that there is no gc_horizon at all, and that tenants with pitr_interval=0 would truly retain no history, so this constant would go away.

Checklist before requesting a review

• I have performed a self-review of my code.
• If it is a core feature, I have added thorough tests.
• Do we need to implement analytics? if so did you add the relevant metrics to the dashboard?
• If this PR requires public announcement, mark it with /release-notes label and add several sentences in this section.

Checklist before merging

• Do not forget to reformat commit message to not include the above checklist

[github-actions]

3079 tests run: 2964 passed, 0 failed, 115 skipped (full report)

---

Flaky tests (3)

Postgres 14

• test_pg_regress[4]: debug
• test_peer_recovery: debug
• test_s3_eviction[0.2-False]: debug

Code coverage* (full report)

• functions: 32.7% (6979 of 21338 functions)
• lines: 50.1% (54986 of 109719 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
5b487b1 at 2024-07-15T13:06:22.884Z :recycle:}

[hlinnaka]

Does the function comment need updating?

Not this PR's fault, but the terminology with the time- and size-based cutoffs are really confusing. "pitr horizon", "cutoff", "retention period" all sound like synonyms to me. Some thoughts:

• How about renaming renaming the cutoff_horizon and pitr variables to wal_size_cutoff and time_cutoff or something similar?
• Does this function (find_gc_cutoffs') really need to return both cutoff values? When perfoming GC, you really only need one Lsn cutoff. Timeline::gc_timeline` keeps statistics of which cutoff value is used per layer, but I don't think that's a very interesting statistic.

[jcsp]

How about renaming renaming the cutoff_horizon and pitr variables to wal_size_cutoff and time_cutoff or something similar?
Does this function (find_gc_cutoffs') really need to return both cutoff values? When perfoming GC, you really only need one Lsn cutoff. Timeline::gc_timeline` keeps statistics of which cutoff value is used per layer, but I don't think that's a very interesting statistic.

Yes to both, let's do this in a separate PR so that we have separate PRs for the functional change and the refactor.

Edit: actually, the distinction between time & space cutoffs is useful for observability, so that we can have metrics that distinguish "how much are retaining because the user asked for it (PITR)'" from "how much are we physically retaining (which may include space-based retention that the user didn't ask for)".

• pageserver: clean up GcCutoffs names #8379