Fix race with LLVM and bison.
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.
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:t139145psql -h localhost -U postgresBuilt from patchset v5 (message #5), September 20, 2026 at 01:00 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 t139145_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 t139145_5 && git checkout t139145_5Patchset v5 (message #5) is on t139145_5
Hi All.
I've found build error in configuration --with-llvm
CPPFLAGS="-O2" ./configure --enable-debug --enable-cassert
--enable-tap-tests --with-openssl --with-icu --with-llvm
....
make world-bin -j3
....
cubescan.c:9:10: fatal error: 'cubeparse.h' file not found
9 | #include "cubeparse.h" /* must be after cubedata.h for YYSTYPE
and NDBOX */
....
segscan.c:9:10: fatal error: 'segparse.h' file not found
9 | #include "segparse.h" /* must be after segdata.h for SEG */
The reason is race, that exist between LLVM compilation and bison source
code generation and compilation can occur first.
Ideally LLVM compilation target should depend on header files targets.
The error is difficult to reproduce and I've done simple patch to have
stable reproducing. Fix patch is also attached.
Thanks.
Attachments:
v1-0002-Patch-simplify-reproducing-of-race-with-LLVM-and-.patchtext/x-patch; charset=UTF-8; name=v1-0002-Patch-simplify-reproducing-of-race-with-LLVM-and-.patchDownload+1-1
v1-0001-Fix-race-with-LLVM-compilation-and-bison-code-gen.patchtext/x-patch; charset=UTF-8; name=v1-0001-Fix-race-with-LLVM-compilation-and-bison-code-gen.patchDownload+8-1
Hi,
On 2026-03-27 14:31:52 +0300, Maksim.Melnikov wrote:
I've found build error in configuration --with-llvm
CPPFLAGS="-O2" ./configure --enable-debug --enable-cassert
--enable-tap-tests --with-openssl --with-icu --with-llvm....
make world-bin -j3
....
cubescan.c:9:10: fatal error: 'cubeparse.h' file not found
9 | #include "cubeparse.h" /* must be after cubedata.h for YYSTYPE and
NDBOX */....
segscan.c:9:10: fatal error: 'segparse.h' file not found
9 | #include "segparse.h" /* must be after segdata.h for SEG */The reason is race, that exist between LLVM compilation and bison source
code generation and compilation can occur first.Ideally LLVM compilation target should depend on header files targets.
The error is difficult to reproduce and I've done simple patch to have
stable reproducing. Fix patch is also attached.
You don't need a sleep to show there's a problem, you can just do
make -C contrib/cube cubescan.bc
We don't have the same issue in the backend, as for backend code each .bc file
depends on the .o file:
src/backend/common.mk:
ifeq ($(with_llvm), yes)
objfiles.txt: $(patsubst %.o,%.bc, $(OBJS))
$(patsubst %.o,%.bc, $(OBJS)): $(OBJS)
endif
But for some reason I didn't add the same logic to pgxs.mk.
I think we need something like the attached to make the dependencies work.
I'm a bit worried about breaking some extensions if were to backpatch this. So
I'm somewhat inclined to just fix this in master.
Greetings,
Andres Freund
Attachments:
fix-llvm-contrib-pgxs-deps.difftext/x-diff; charset=us-asciiDownload+8-0
Hi
On 3/27/26 21:56, Andres Freund wrote:
Hi,
On 2026-03-27 14:31:52 +0300, Maksim.Melnikov wrote:
I've found build error in configuration --with-llvm
CPPFLAGS="-O2" ./configure --enable-debug --enable-cassert
--enable-tap-tests --with-openssl --with-icu --with-llvm....
make world-bin -j3
....
cubescan.c:9:10: fatal error: 'cubeparse.h' file not found
9 | #include "cubeparse.h" /* must be after cubedata.h for YYSTYPE and
NDBOX */....
segscan.c:9:10: fatal error: 'segparse.h' file not found
9 | #include "segparse.h" /* must be after segdata.h for SEG */The reason is race, that exist between LLVM compilation and bison source
code generation and compilation can occur first.Ideally LLVM compilation target should depend on header files targets.
The error is difficult to reproduce and I've done simple patch to have
stable reproducing. Fix patch is also attached.You don't need a sleep to show there's a problem, you can just do
make -C contrib/cube cubescan.bcWe don't have the same issue in the backend, as for backend code each .bc file
depends on the .o file:src/backend/common.mk:
ifeq ($(with_llvm), yes)
objfiles.txt: $(patsubst %.o,%.bc, $(OBJS))
$(patsubst %.o,%.bc, $(OBJS)): $(OBJS)
endifBut for some reason I didn't add the same logic to pgxs.mk.
I think we need something like the attached to make the dependencies work.
I'm a bit worried about breaking some extensions if were to backpatch this. So
I'm somewhat inclined to just fix this in master.Greetings,
Andres Freund
Thanks for attentions, I see your patch is better. Few additional thoughts
1. Now I see that we have two different places to configure backend and
extensions, maybe we should
apply your patch to some common place, for example
src/Makefile.global.in, because it seems common
build logic. How do you think?
2. If you have some doubts about backpatch, I suggest to apply
fix-llvm-contrib-pgxs-deps.diff on master
and patch
v2-0001-Fix-race-with-LLVM-compilation-and-bison-code-gen.patch as
backpatch, because this one
correct it only for problematic contribs. How do you think?
Greetings,
Maksim Melnikov
I think we need something like the attached to make the dependencies work.
I'm a bit worried about breaking some extensions if were to backpatch this. So
I'm somewhat inclined to just fix this in master.
pg_plan_advice also seems to be affected and is missing from the
original patch, a generic fix like this handles that too and all
future cases.
On 3/31/26 01:37, Zsolt Parragi wrote:
I think we need something like the attached to make the dependencies work.
I'm a bit worried about breaking some extensions if were to backpatch this. So
I'm somewhat inclined to just fix this in master.pg_plan_advice also seems to be affected and is missing from the
original patch, a generic fix like this handles that too and all
future cases.
Yes, It will be okay with Andres fix.
I've noticed that Andres patch wasn't moved to CF, so I feel free to add
Andres patch to commitfest [0]https://commitfest.postgresql.org/patch/7206, I apologize if it isn't good.
Best regards
Maksim Melnikov