Hi Tomas,
Thanks for v3. One small documentation inconsistency in the disable
function before this goes in.
In func-admin.sgml the signature of pg_disable_data_checksums documents
the default as false:
pg_disable_data_checksums ( fast bool DEFAULT false )
but the actual default is true. pg_proc.dat sets
proargdefaults => '{true}'
and the prose you added right below the signature also says:
The default value is true.
On Wed, Jul 8, 2026 at 6:36 AM Tomas Vondra <[email protected]> wrote:
>
> On 7/7/26 23:00, Daniel Gustafsson wrote:
> >> 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?
> >
>
> 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
--
Regards,
Ewan Young
