Re: [PATCH] Identify LWLocks in tracepoints

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Identify LWLocks in tracepoints
Date: 2021-05-09 18:55:04
Message-ID: 20210509185504.svhnhufbulq756vv@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2021-05-08 13:13:47 -0400, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> > On 05.05.21 00:15, Andres Freund wrote:
> >> I'm now getting
> >> /home/andres/src/postgresql/src/backend/storage/lmgr/lwlock.c: In function ‘LWLockAcquire’:
> >> /home/andres/src/postgresql/src/backend/storage/lmgr/lwlock.c:1322:58: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
> >> 1322 | TRACE_POSTGRESQL_LWLOCK_WAIT_START(T_NAME(lock), mode);
> >> | ^
>
> > What compiler are you using in this situation?

gcc - I think the warning is pulled in via -Wextra. I think it's
something sensible to warn about, too easy to end up with misleading
behaviour when statement-like macros are defined empty.

> All of these buildfarm members are now showing this warning:
>
> calliphoridae gcc (Debian 10.1.0-6) 10.1.0
> culicidae gcc (Debian 10.1.0-6) 10.1.0
> flaviventris gcc (Debian 20200124-1) 10.0.1 20200124 (experimental)
> francolin gcc (Debian 10.1.0-6) 10.1.0
> piculetœ gcc (Debian 10.1.0-6) 10.1.0
> rorqual gcc (Debian 10.1.0-6) 10.1.0
> serinus gcc (Debian 20200124-1) 10.0.1 20200124 (experimental)
> skink gcc (Debian 10.1.0-6) 10.1.0

I think those likely are all mine, so it's not too surprising. They all
use something like
CFLAGS => '-Og -ggdb -g3 -Wall -Wextra -Wno-unused-parameter -Wno-sign-compare -Wno-missing-field-initializers -fno-omit-frame-pointer',

> (I wonder why flaviventris and serinus are still using an "experimental"
> compiler version that is now behind mainstream.)

The upgrade script didn't install the newer version it because it had to
remove some conflicting packages... Should be fixed for runs starting
now.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-05-09 19:04:41 Re: plan with result cache is very slow when work_mem is not enough
Previous Message Tom Lane 2021-05-09 17:01:38 Re: Reducing opr_sanity test's runtime under CLOBBER_CACHE_ALWAYS