Hi, On Thu, Aug 27, 2026 at 10:15 AM Daniel Gustafsson <[email protected]> wrote: > > > 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.
It silently ignores the fork failure. One can still look at the progress report or server logs to find that, but I think having this fixed in a simple way is better. > > 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. Here's my first attempt at fixing this without changing the function return types. In the best case, waiting for the background worker to start is very short, and if any failure is detected in forking the worker, these functions error out (similar to apw_start_leader_worker()). I still think this needs to be tightened in PG19 as well, but I'm fine with HEAD only. Please have a look at the attached patch. -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com
v1-0001-Report-an-error-when-the-data-checksums-worker-fa.patch
Description: Binary data
