> On 27 Aug 2026, at 19:04, Bharath Rupireddy > <[email protected]> wrote:
> pg_enable_data_checksums() and pg_disable_data_checksums() start a > launcher background worker via StartDataChecksumsWorkerLauncher() and > then return immediately. The function errors out if registration > fails, but it does not check whether the launcher actually started > after that. If the postmaster registers the launcher but then fails to > fork it (e.g., fork failure under memory pressure), the SQL function > still returns success, the launcher never runs. The functions return void and were designed to initiate processing but not track any level of progress, since processing can take a long time. > The caller gets no indication that the requested operation did not happen. I > reproduced > this with an induced fork failure, so I think we need to tighten this > for both PG19 and HEAD branches. There is also no indication of the operation succeeding from the functions, pg_stat_activity has the details for this. It's too late to change the function signature for PG19. > Fix would be to check > GetBackgroundWorkerPid()/WaitForBackgroundWorkerStartup() and error > out when the worker has not started. If okay, I can send a patch. I'm not convinced there is much value in adding such complexity as it would have to handle more cases than that to be useful. There is pg_stat_progress_data_checksums which can be queried for details on the processing. It's too late for v19 (in more ways than one perhaps), but feel free to post a suggestion for HEAD and we can evaluate it from there. -- Daniel Gustafsson
