new clang warnings about unused global variables
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
This thread has been committed, so CI has stopped here. Anything below is the last result it produced.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253597psql -h localhost -U postgresBuilt from patchset v5 (message #5), September 10, 2026 at 04:26 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253597_5 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253597_5 && git checkout t253597_5Patchset v5 (message #5) is on t253597_5
The new clang 23 has a new warning apparently enabled by default (at
least by default in a PostgreSQL build) about set-but-unused static
global variables: -Wunused-but-set-global. This triggers a few warnings
in PostgreSQL code. See attached patches. The first four of these are
genuine hits; these variables were never read from or the last reading
use was removed some time ago. The last one in pg_ctl is about options
that can be set from the command line on any platform but are only used
on Windows. This seems kind of weird behavior; maybe in the future we
should make those options error out on non-Windows, and then the
variables wouldn't be uselessly set.
Attachments:
t253597_10001-Remove-unused-global-variable-xlog.c.patchtext/plain; charset=UTF-8; name=0001-Remove-unused-global-variable-xlog.c.patchDownload+0-11
0002-Remove-unused-global-variable-test_resowner.patchtext/plain; charset=UTF-8; name=0002-Remove-unused-global-variable-test_resowner.patchDownload+1-6
0003-Remove-unused-global-variable-pg_dump.patchtext/plain; charset=UTF-8; name=0003-Remove-unused-global-variable-pg_dump.patchDownload+0-3
0004-Remove-unused-global-variable-postmaster.patchtext/plain; charset=UTF-8; name=0004-Remove-unused-global-variable-postmaster.patchDownload+0-4
0005-Silence-warnings-about-unused-global-variables-pg_ct.patchtext/plain; charset=UTF-8; name=0005-Silence-warnings-about-unused-global-variables-pg_ct.patchDownload+5-6
On 28.08.26 23:33, Peter Eisentraut wrote:
The new clang 23 has a new warning apparently enabled by default (at
least by default in a PostgreSQL build) about set-but-unused static
global variables: -Wunused-but-set-global. This triggers a few warnings
in PostgreSQL code. See attached patches. The first four of these are
genuine hits; these variables were never read from or the last reading
use was removed some time ago. The last one in pg_ctl is about options
that can be set from the command line on any platform but are only used
on Windows. This seems kind of weird behavior; maybe in the future we
should make those options error out on non-Windows, and then the
variables wouldn't be uselessly set.
I sense that nobody is going to have issues with this. Any objections
to backpatching this? I suspect that over time many more people are
going to run into this, so keeping the backbranches warning-free seems
sensible.
On 9/3/26 15:01, Peter Eisentraut wrote:
On 28.08.26 23:33, Peter Eisentraut wrote:
The new clang 23 has a new warning apparently enabled by default (at
least by default in a PostgreSQL build) about set-but-unused static
global variables: -Wunused-but-set-global. This triggers a few
warnings in PostgreSQL code. See attached patches. The first four of
these are genuine hits; these variables were never read from or the
last reading use was removed some time ago. The last one in pg_ctl is
about options that can be set from the command line on any platform
but are only used on Windows. This seems kind of weird behavior;
maybe in the future we should make those options error out on non-
Windows, and then the variables wouldn't be uselessly set.
The rest look good but ot sure I like the last patch. Wouldn't we want
to get an error on unused on Windows builds? The patch would hide if we
stop using one of them on Windows.
I sense that nobody is going to have issues with this. Any objections
to backpatching this? I suspect that over time many more people are
going to run into this, so keeping the backbranches warning-free seems
sensible.
Yeah, as the changes are simple and only touch unused static globals I
do not see any risk with backporting.
--
Andreas Karlsson
Percona
Peter Eisentraut <peter@eisentraut.org> writes:
I sense that nobody is going to have issues with this. Any objections
to backpatching this? I suspect that over time many more people are
going to run into this, so keeping the backbranches warning-free seems
sensible.
Agreed, we usually like to keep the back branches warning-free too.
But I concur with Andreas that 0005 looks a bit half-baked.
Maybe that's the right amount of effort for the back branches,
but something else should happen in HEAD.
regards, tom lane
On 03.09.26 15:52, Tom Lane wrote:
Peter Eisentraut <peter@eisentraut.org> writes:
I sense that nobody is going to have issues with this. Any objections
to backpatching this? I suspect that over time many more people are
going to run into this, so keeping the backbranches warning-free seems
sensible.Agreed, we usually like to keep the back branches warning-free too.
But I concur with Andreas that 0005 looks a bit half-baked.
Maybe that's the right amount of effort for the back branches,
but something else should happen in HEAD.
Right. Here is another patch at the end (0006) that I propose for
master only that makes using unsupported options an error. Some
Windows-only options already behaved that way, so this just makes the
rest consistent.
Attachments:
t253597_5v2-0001-Remove-unused-global-variable-xlog.c.patchtext/plain; charset=UTF-8; name=v2-0001-Remove-unused-global-variable-xlog.c.patchDownload+0-11
v2-0002-Remove-unused-global-variable-test_resowner.patchtext/plain; charset=UTF-8; name=v2-0002-Remove-unused-global-variable-test_resowner.patchDownload+1-6
v2-0003-Remove-unused-global-variable-pg_dump.patchtext/plain; charset=UTF-8; name=v2-0003-Remove-unused-global-variable-pg_dump.patchDownload+0-3
v2-0004-Remove-unused-global-variable-postmaster.patchtext/plain; charset=UTF-8; name=v2-0004-Remove-unused-global-variable-postmaster.patchDownload+0-4
v2-0005-Silence-warnings-about-unused-global-variables-pg.patchtext/plain; charset=UTF-8; name=v2-0005-Silence-warnings-about-unused-global-variables-pg.patchDownload+5-6
v2-0006-pg_ctl-Error-out-on-Windows-only-options-elsewher.patchtext/plain; charset=UTF-8; name=v2-0006-pg_ctl-Error-out-on-Windows-only-options-elsewher.patchDownload+37-8
Peter Eisentraut <peter@eisentraut.org> writes:
On 03.09.26 15:52, Tom Lane wrote:
But I concur with Andreas that 0005 looks a bit half-baked.
Maybe that's the right amount of effort for the back branches,
but something else should happen in HEAD.
Right. Here is another patch at the end (0006) that I propose for
master only that makes using unsupported options an error. Some
Windows-only options already behaved that way, so this just makes the
rest consistent.
With that addition, this looks fine to me.
regards, tom lane
On 07.09.26 20:39, Tom Lane wrote:
Peter Eisentraut <peter@eisentraut.org> writes:
On 03.09.26 15:52, Tom Lane wrote:
But I concur with Andreas that 0005 looks a bit half-baked.
Maybe that's the right amount of effort for the back branches,
but something else should happen in HEAD.Right. Here is another patch at the end (0006) that I propose for
master only that makes using unsupported options an error. Some
Windows-only options already behaved that way, so this just makes the
rest consistent.With that addition, this looks fine to me.
This has been committed and backpatched. There were a few more issues
of this kind in the backbranches, which I have also fixed.