Hi Hackers, Daniel, Further testing this feature, I noticed that the cost_delay and cost_limit arguments to pg_enable_data_checksums() in practice have no effect.
It appears we have two independent issues in DataChecksumsWorkerMain(): (1) The worker writes the user-supplied values to VacuumCostDelay and VacuumCostLimit (the GUC-bound globals in globals.c). However, vacuum_delay_point() reads vacuum_cost_delay / vacuum_cost_limit declared in vacuum.c. The two pairs are kept in sync only by VacuumUpdateCosts(), which the worker never calls. Therefore, the napping formula always sees the defaults (vacuum_cost_delay = 0) and never sleeps. (2) The worker also resets VacuumCostPageHit/Miss/Dirty to 0 at startup. With all per-page weights at zero, VacuumCostBalance never reaches vacuum_cost_limit, which would defeat the throttling on its own even if (1) were fixed. Repro: Create a database and load data (say 3 GB) SELECT pg_disable_data_checksums(); SELECT pg_enable_data_checksums(100, 1); -- 100 ms/page, balance limit 1 Without the fix, this completes in ~10 seconds and pg_stat_activity never shows wait_event = VacuumDelay for the worker. With even moderate parameters (e.g. (50, 200)) the worker is continuously in VacuumDelay after the patch, and total runtime stretches as one would expect. Also manually tested with cost_delay 0 and higher cost limits. Attached a patch to fix this. Thanks, Satya
0001-Apply-data-checksum-worker-throttling-parameters.patch
Description: Binary data
