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
