On Sun, Dec 03, 2023 at 11:07:05AM -0800, Noah Misch wrote: > Can be, but the WAL_DEBUG model is mighty convenient: > - Cooperates with backtrace_functions > - Change log_line_prefix to correlate any log_line_prefix fact with WAL > records > - See WAL records interleaved with non-WAL log messages > > I don't use it in production, but I use it more than any other of our many > DEBUG macros.
So do I as a quick workaround to check the validity of records generated without having to spawn a standby replaying the records. Since 027_stream_regress.pl exists, I agree that its value has decreased and that all patches should have queries to check their records anyway, but it does not make it useless for developers. > Fixing tests is less valuable, especially since it's clear when a test fails > through extra messages the test didn't expect. I bet other DEBUG macros make > some tests fail that way, which doesn't devalue those macros. A test patch > might be okay nonetheless, but a buildfarm member is more likely to have > negative value. It would create urgent work. In the hypothetical buildfarm > member's absence, the project would be just fine if that work never happens. > A buildfarm member that compiles but doesn't test could be okay. I can add the flag in one of my nix animals if we don't have any to provide minimal coverage, that's not an issue for me. I'd suggest to just fix the build on Windows, this flag is a low maintenance burden. -- Michael
signature.asc
Description: PGP signature
