Re: Is WAL_DEBUG related code still relevant today?
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-12-02T22:30:43Z
Lists: pgsql-hackers
On Sat, Dec 02, 2023 at 07:36:29PM +0530, Bharath Rupireddy wrote: > I started to think if this code is needed at all in production. How > about we do either of the following? Well, the fact that this code is hidden behind an off-by-default macro seems like a pretty strong indicator that it is not intended for production. But that doesn't mean we should remove it. > a) Remove the WAL_DEBUG macro and move all the code under the > wal_debug GUC? Since the GUC is already marked as DEVELOPER_OPTION, > the users will know the consequences of enabling it in production. I think the key to this option is verifying there's no measurable performance impact. > b) Remove both the WAL_DEBUG macro and the wal_debug GUC. I don't > think (2) is needed to be in core especially when tools like > pg_walinspect and pg_waldump can do the same job. And, the messages in > (3) and (4) can be turned to some DEBUGX level without being under the > WAL_DEBUG macro. Is there anything provided by wal_debug that can't be found via pg_walinspect/pg_waldump? > I have no idea if anyone uses WAL_DEBUG macro and wal_debug GUCs in > production, if we have somebody using it, I think we need to fix the > compilation and test failure issues, and start testing this code > (perhaps I can think of setting up a buildfarm member to help here). +1 for at least fixing the code and tests, provided we decide to keep it. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Commits
-
Remove trace_recovery_messages
- c7a3e6b46d38 17.0 landed
-
Fix compilation on Windows with WAL_DEBUG
- 7d5a740331bf 13.14 landed
- c49b6cab1e66 14.11 landed
- 87ed81a8739b 15.6 landed
- 6248a2bb92cc 16.2 landed
- 7636725b922c 17.0 landed