Stop waiting for a spread checkpoint when taking a base backup One flag. `pg_basebackup` waits for a checkpoint, and by default it asks for a *spread* one — paced over `checkpoint_completion_target` of the checkpoint interval. The wait is therefore proportional to how busy the server is, and a server you are taking a standby from is busy by definition, because a suite is running against it. `--checkpoint=fast` asks for the checkpoint immediately, which is what it is for. ## What it was costing | | | |---|---| | this package's suite | **78s → 1.5s** | | starting one standby | **~13.5s → ~0.17s** | Measured downstream, where it was found: a mutation check that instruments one library and reruns its suite once per mutant ran for **2.5 hours** at a load average of 0.5 on 64 cores. It was not computing, it was waiting for `pg_basebackup`, thousands of times over. It now takes 342 seconds. The cost is invisible amortised over a suite, which is why it shipped: 13.5 seconds spread across a 514-test suite is nothing, and that is how it was measured. Per process it is the whole cost, and mutation testing is one process per mutant. ## Why this is separate This was originally one PR together with making the standby start lazily, on the theory that a suite should not pay for a replica it never reads. Measuring the two apart says the flag is the fix and the laziness is nearly free of benefit on top of it: with `--checkpoint=fast` in, deferring the standby saves **0.17s** per process that never reads a replica. That change is in the PR stacked on this one, with the numbers, so it can be judged on its own. ## Not breaking `0.5.1.0`. No API change.