Thank you for the feedback! > but the invasiveness and the footprint this involves in > the WAL insertion code paths makes it a no-go for me.
Invasiveness is an option I choose, not a requirement. In an alternative version, this could work in a "less strict" mode, on top of Alexander's memset patch, verifying that: if we see a function that uses XLogRegisterData, and the variable passed to it is defined in the same function/translation unit (which is most of the case), we require that variable to be well initialized - either all fields have to be specified by hand, or it needs an initializer block/memset at the beginning -- or if it has compiler generated padding inside, it requires memset, as that's the only thing guaranteed to initialize it. Similarly instead of requiring explicit padding added to the end of the struct, it could instead verify that 1. the SizeOf macros are correctly defined, refer to the proper size 2. if a SizeOf macro is defined, the struct is properly memset at every location where it it used In that version, there would be little or no change over Alexander's previous patch, other than adding pg-tidy itself to the build. I can also create a version with that approach, it should be relatively simply as I won't have to modify the WAL structs/calls like in this version. > Valgrind has proved to be quite useful over the years. Sure, it takes > more time to run it, but for this specific issue I don't see why we > should not continue relying on it I'm not saying that we should rely on valgrind, it is a good tool and it possibly catches things this wouldn't. This would be an additional tool, offering the advantage of being quick and integrated into the build. (Valgrind is also integrated, but it is also slow, I don't think everyone runs it regularly as part of normal development)
