Re: allow spread checkpoints when changing checksums online

> On 6 Jul 2026, at 13:43, Tomas Vondra <tomas(at)vondra(dot)me> wrote:

> Here's a rebased patch, addressing the minor bitrot, and with some very
> minor adjustments.

Thanks for picking up this!

> 3) I've noticed the SGML docs don't have default values for the existing
> parameters (cost_delay, cost_limit), so I added those. Maybe backpatch?

+1, that sounds like a good idea.

> 4) I've added the new 'fast' parameter to the DataChecksums module, but
> mostly just for completeness. The TAP tests still use the default value,
> so that it doesn't take longer.

+ spread (throttled), which may increase the time needed to enable checksums,

I think we should stick to the "data checksums" terminology for consistency.

@@ -1676,6 +1686,7 @@ DataChecksumsWorkerMain(Datum arg)

DataChecksumState->cost_delay = DataChecksumState->launch_cost_delay;
DataChecksumState->cost_limit = DataChecksumState->launch_cost_limit;
+ DataChecksumState->fast_checkpoint = DataChecksumState->launch_fast_checkpoint;
}
else
costs_updated = false;

This update will only change the fast parameter if cost_limit or cost_delay
were changed, shouldn't the fast parameter also be checked for runtime update?

> I've spent some time thinking about the default value. For a while I
> thought maybe it should default to 'false' (in which case we use spread
> checkpoints, which is the less disruptive option).
>
> But that's actually futile, because the cost_delay still defaults to 0,
> which means the "data page rewrite" phase won't be paced. It seems
> surprising the first phase would not be throttled by default, while the
> checkpoints are ...
>
> So I ended up setting the 'fast=true' default.

I think fast=true is the right default.

> This is not a very complicated patch, and it's been part of the old
> patch series for quite a while. So unless there's some objections I'll
> get this committed in a couple days.

+1

--
Daniel Gustafsson