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