Fix pg_stat_progress_data_checksums counter initialization

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Fix pg_stat_progress_data_checksums counter initialization
Date: 2026-07-10 07:13:56
Message-ID: CAHGQGwEOQyEzW2cqrHEzvwbcsAsuH8MEe7MMidFOFxECy0E1_Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

The pg_stat_progress_data_checksums docs says that databases_total and
databases_done are reported as NULL for workers, but I observed that
they are reported as 0 instead:

=# select * from pg_stat_progress_data_checksums;
pid | datid | datname | phase | databases_total |
databases_done | relations_total | relations_done | blocks_total |
blocks_done
-------+-------+----------+----------+-----------------+----------------+-----------------+----------------+--------------+-------------
34873 | 0 | (null) | enabling | 3 |
0 | (null) | (null) | (null) | (null)
34874 | 5 | postgres | enabling | 0 |
0 | 297 | 0 | 163935 | 427
(2 rows)

The cause is that pg_stat_progress_data_checksums uses -1 as the
sentinel value displayed as NULL, but pgstat_progress_start_command()
initializes all progress counters to zero. Data checksum progress did not
consistently reset those counters to -1, so some counters could
incorrectly appear as 0 instead of NULL.

The attached patch fixes this by initializing all data checksum progress
counters to -1 immediately after progress reporting starts for both
launcher and worker processes.

While looking at this code, I also found that blocks_done is not reset
when a worker starts processing a new relation fork. As a result,
blocks_done can temporarily exceed blocks_total, or a stale blocks_done
value can remain visible for an empty relation fork. The attached patch
resets blocks_done together with blocks_total when starting each
relation fork.

Regards,

--
Fujii Masao

Attachment Content-Type Size
v1-0001-Fix-data-checksum-progress-counter-initialization.patch application/octet-stream 7.2 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2026-07-10 07:31:15 Re: Possible typo in an error message
Previous Message vignesh C 2026-07-10 07:00:02 Re: sequencesync worker race with REFRESH SEQUENCES