> On 6 Jul 2026, at 13:43, Tomas Vondra <[email protected]> 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
