Re: Changing the state of data checksums in a running cluster

> On 15 Mar 2026, at 23:47, Tomas Vondra <tomas(at)vondra(dot)me> wrote:

>> * The change to XLOG_CHECKPOINT_REDO to move the wal_level into a proper record
>> structure should be pulled out as a 0001 patch as it's an cleanup that has
>> value on its own.
>
> Makes sense, but it's going to be harder because since d774072f0040 all
> 4 bits in XLR_INFO are used.

Fixed by adding a second XLOG rmgr.

> 1) Is this actually doing the expected thing?
>
> INJECTION_POINT("datachecksumsworker-initial-dblist", DatabaseList);
>
> We're passing a regular pointer to the database list, so can the
> injection point actually modify it? I suppose it happens to work because
> dc_dblist() removes the last item, so the pointer to the list does not
> change. But that's luck.

Fixed.

> 2) ProcessAllDatabases may be misusing processed_databases

Good point, we need to track both the number of processed as well as the
cumulative total.

> 3) DATACHECKSUMSWORKER_MAX_DB_RETRIES / DATACHECKSUMSWORKER_FAILED
>
> What happens if a database reaches the maximum number of retries? We
> mark that entry as failed, but AFAIK we'll still try to process any
> remaining databases. Isn't that already doomed and we won't be able to
> enable checksums? So why not to simply abort the loop right away?

It might be, but it can also fail because it is concurrently dropped, in that
case we don't consider it a failure as it is the expected outcome. This is
tested for at the end of the loop, but maybe it can be detected sooner to error
out early on actual failures.

--
Daniel Gustafsson