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
v1-0001-Fix-data-checksum-progress-counter-initialization.patch
Description: Binary data
