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
