Horton

Little checksum worker cleanups

Heikki Linnakangas <hlinnaka@iki.fi>

View thread View on postgr.es
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Daniel Gustafsson <daniel@yesql.se>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2026-06-23T20:40:20Z
Lists: pgsql-hackers

Attachments

Hi,

I had another fresh look at datachecksum_state.c while rebasing my 
"Interrupts vs signals" patch set, and spotted a few minor things that I 
think should be cleaned up. See commit messages for details.

Unless I'm missing something, the last patch fixes a bug, albeit a very 
theoretical one. The crux is that when the launcher exits, the worker 
might be left running; launcher_exit sends it SIGTERM but it might not 
exit instantly. If the launcher is restarted, and it launches a new 
worker while the old one is still running, the old launcher might set 
the worker's result field in shared memory, misleading the launcher to 
believe that the *new* worker succeeded.

That'd race condition would be really hard to hit in practice - I didn't 
even try to write a test - but it'd be nice to fix it. The patch adds a 
unique ID to each worker invocation to distinguish the old and new 
worker if both are running at the same time, ensuring that the old 
worker doesn't mess with the new worker's state.

- Heikki

Commits

  1. Distinguish datacheckums worker invocations more reliably

  2. Minor cleanup around checking datachecksum worker result

  3. Avoid leaving DataChecksumState->worker_pid to an old value

  4. Misc cleanup in datachecksums_state.[ch]