Re: race condition when writing pg_control

On 2024-May-18, Thomas Munro wrote:

> First idea idea I've come up with to avoid all of that: pass a copy of
> the "proto-controlfile", to coin a term for the one read early in
> postmaster startup by LocalProcessControlFile(). As far as I know,
> the only reason we need it is to suck some settings out of it that
> don't change while a cluster is running (mostly can't change after
> initdb, and checksums can only be {en,dis}abled while down). Right?
> Children can just "import" that sucker instead of calling
> LocalProcessControlFile() to figure out the size of WAL segments yada
> yada, I think? Later they will attach to the real one in shared
> memory for all future purposes, once normal interlocking is allowed.
>
> I dunno. Draft patch attached. Better plans welcome. This passes CI
> on Linux systems afflicted by EXEC_BACKEND, and Windows. Thoughts?

Has this problem been addressed? Looking at the known-buildfarm-
failures page,
https://wiki.postgresql.org/wiki/Known_Buildfarm_Test_Failures#culicidae_failed_to_restart_server_due_to_incorrect_checksum_in_control_file
there are still some failures of that ilk, last in 2026-01-21.

So, was this "proto-controlfile" idea discarded? I see Noah downthread
proposed something somewhat more sophisticated than this, setting some
values to garbage to prevent reading invalid values. I imagine that
would be on top of Thomas' patch, so I have rebased it and moved to the
next commitfest.

Thanks

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Crear es tan difícil como ser libre" (Elsa Triolet)