On Thu, Feb 26, 2026 at 03:53:54PM +0100, Matthias van de Meent wrote: > In 2025, Noah sent a mail to -hackers [1] showing a race condition > that could get this flag to be set on incorrect WAL pages, which could > cause issues for software that relied on this flag's indicated value. > > Finally, I (and Michael in 2018 [2]) also couldn't find any code in > any of release branches >= 9.2 that used this flag, I couldn't find > any user in Debian Code Search, nor did I find any code on Github that > would indicate any real usage of that flag: There are some WAL > decoding tools that display its presence on the page, or which copy > the definition into their respective project in their language of > choice, but never any that have material logic that utilizes whatever > this flag means for more than displaying the WAL page state.
Noah's statement is a better argument than the impression I got from 2018 (aka it's useless): even if one tries to use this flag, it may report a different fact than what one wants to track. Let's just remove this flag. I would have let XLP_ALL_FLAGS as it is now at 0x000F, though. It is just used for filtering the bits we allow to exist in this area of the header, for validation. Perhaps some forks like this extensibility if they have their own extra custom bits, meaning less code to modify. That's a minor point for sure, but people like hacking on Postgres and forking this code. Thoughts or objections from others? -- Michael
signature.asc
Description: PGP signature
