Online enable/disable data checksums functions return success even when the launcher fails to start
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253579psql -h localhost -U postgresBuilt from patchset v3 (message #3), September 20, 2026 at 05:10 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253579_3 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253579_3 && git checkout t253579_3Patchset v3 (message #3) is on t253579_3
Hi,
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 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.
Fix would be to check
GetBackgroundWorkerPid()/WaitForBackgroundWorkerStartup() and error
out when the worker has not started. If okay, I can send a patch.
Thoughts?
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
On 27 Aug 2026, at 19:04, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> 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
Hi,
On Thu, Aug 27, 2026 at 10:15 AM Daniel Gustafsson <daniel@yesql.se> wrote:
On 27 Aug 2026, at 19:04, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> 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
On 29 Aug 2026, at 07:09, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote:
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()).
It may be short (for some value of) in best case, but my concern is that it
will in every case be impossible to determine in what timeframe it will return.
It's also not replacing any bit of monitoring required. Also, this is just the
launcher, and gives no insight into the workers doing the actual heavy lifting.
I still think this needs to be tightened in PG19 as well, but I'm fine with
HEAD only.
Every bit of behavioural change is out of scope for v19 IMO, we are post beta3
and should only fix bugs and regressions. Pursuing it for v20 is another thing
of course, so I would recommend registering in the commitfest and someone else
might think I'm completely wrong, which is fine.
--
Daniel Gustafsson