Re: Remove unnecessary "lmgr.h" in stat_utils.c

From: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Subject: Re: Remove unnecessary "lmgr.h" in stat_utils.c
Date: 2025-05-07 17:56:55
Message-ID: aBue54ldbPeJrHZM@ip-10-97-1-34.eu-west-3.compute.internal
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Wed, May 07, 2025 at 07:28:01AM +0000, Bertrand Drouvot wrote:
> Hi,
>
> On Wed, May 07, 2025 at 09:10:17AM +0900, Michael Paquier wrote:
> > On Mon, May 05, 2025 at 04:33:20PM +0300, Ilia Evdokimov wrote:
> > > While reviewing the import/export statistics, I noticed that relation
> > > locking are handled via relation_open() and relation_close() in
> > > stats_lock_check_privileges(), and no calls to other lock-manager routines
> > > are actually used there. As a result, the inclusion of the lock-manager
> > > header
> > >
> > > #include "storage/lmgr.h"
> > >
> > > is not needed. I have attached a small patch which simply removes that
> > > include.
> >
> > True that we try to be clean when it comes to that.
>
> Re-sharing my thoughts as it looks like that my previous email did not reach the
> mailing list (yet?): probably because the attachement mentioned below was too
> large.
>
> "
> Thanks for the report!
>
> Indeed, and that's what clang-tidy (misc-include-cleaner) also reports:
>
> $ run-clang-tidy -checks="-*,misc-include-cleaner" | grep "is not used directly" | grep stat_utils.c
> ../src/backend/statistics/stat_utils.c:26:1: warning: included header lmgr.h is not used directly [misc-include-cleaner]
>
> Actually it reports much more (see attached):
>
> $ run-clang-tidy -checks="-*,misc-include-cleaner" | grep -c "is not used directly"
> 794
>
> I did not look to check if all of them make sense (I'd guess probably not), but
> I'm wondering if it would make sense to work an a "larger" cleanup instead?
> (in the same vein as [1] did)
>
> [1]: https://www.postgresql.org/message-id/af837490-6b2f-46df-ba05-37ea6a6653fc%40eisentraut.org
>
> "

FWIW, please find attached a subset of the initial report that focus on
the "is not used directly" warnings.

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

Attachment Content-Type Size
report_is_not_used_directly.txt text/plain 94.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2025-05-07 18:13:24 [PATCH] oauth: Prevent stack overflow by limiting JSON parse depth
Previous Message Daniel Gustafsson 2025-05-07 17:53:38 Re: disabled SSL log_like tests