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)