pageserver: add no_sync for use in regression tests (1/2)

[jcsp]

Problem

In test environments, the syncfs that the pageserver does on startup can take a long time, as other tests running concurrently might have many gigabytes of dirty pages.

Summary of changes

• Add a no_sync option to the pageserver's config.
• Skip syncfs on startup if this is set
• A subsequent PR (pageserver: add no_sync for use in regression tests (2/2) #9678) will enable this by default in tests. We need to wait until after the next release to avoid breaking compat tests, which would fail if we set no_sync & use an old pageserver binary.

Q: Why is this a different mechanism than safekeeper, which as a --no-sync CLI?
A: Because the way we manage pageservers in neon_local depends on the pageserver.toml containing the full configuration, whereas safekeepers have a config file which is neon-local-specific and can drive a CLI flag.

Q: Why is the option no_sync rather than sync?
A: For boolean configs with a dangerous value, it's preferable to make "false" the safe option, so that any downstream future config tooling that might have a "booleans are false by default" behavior (e.g. golang structs) is safe by default.

Q: Why only skip the syncfs, and not all fsyncs?
A: Skipping all fsyncs would require more code changes, and the most acute problem isn't fsyncs themselves (these just slow down a running test), it's the syncfs (which makes a pageserver startup slow as a result of other tests)

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]

5337 tests run: 5115 passed, 0 failed, 222 skipped (full report)

---

Flaky tests (1)

Postgres 17

• test_sharding_split_failures[failure12]: debug-x86-64

Code coverage* (full report)

• functions: 31.7% (7854 of 24775 functions)
• lines: 49.4% (62119 of 125849 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
2aa794a at 2024-11-07T16:55:01.305Z :recycle:}

[arpad-m]

Maybe rename it to no_startup_sync instead of no_sync? Latter name might be confused for a "don't do any fsyncs at all" option (which it isn't). In fact, the safekeeper no_sync option is such a "don't do any fsyncs at all" option.

[jcsp]

Maybe rename it to no_startup_sync instead of no_sync? Latter name might be confused for a "don't do any fsyncs at all" option (which it isn't). In fact, the safekeeper no_sync option is such a "don't do any fsyncs at all" option.

I was a bit intentionally vague with the name, as in future we might extend it to fsyncs in general, and I wouldn't want to have two separate configs