Re: allow spread checkpoints when changing checksums online

On 7/7/26 23:00, Daniel Gustafsson wrote:
>> 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?
>

Ah, good catch. I missed that. The attached v3 fixes this.

>> 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.
>

Ack

>> 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

Thanks!

--
Tomas Vondra