public inbox for [email protected]
help / color / mirror / Atom feedFrom: Ewan Young <[email protected]>
To: Tomas Vondra <[email protected]>
Cc: Daniel Gustafsson <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: allow spread checkpoints when changing checksums online
Date: Wed, 8 Jul 2026 19:53:26 +0800
Message-ID: <CAON2xHPXQPJKrX3MGB3ZP4XGKd0TCG-u=5iotUi24-1ALZdCdw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
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
view thread (8+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: allow spread checkpoints when changing checksums online
In-Reply-To: <CAON2xHPXQPJKrX3MGB3ZP4XGKd0TCG-u=5iotUi24-1ALZdCdw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox