Bjorn Munch reported off-list that this sequence: unpack tarball, cd into it ./configure ... cd src/test/regress make
no longer works in 9.6beta2, where it did work in previous releases. I have confirmed both statements. The failure looks like gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g -O1 -fpic -I../../../src/include -D_GNU_SOURCE -c -o regress.o regress.c In file included from ../../../src/include/storage/lock.h:23, from ../../../src/include/access/heapam.h:22, from ../../../src/include/nodes/execnodes.h:18, from ../../../src/include/commands/trigger.h:17, from regress.c:29: ../../../src/include/storage/lwlock.h:129:33: error: storage/lwlocknames.h: No such file or directory make: *** [regress.o] Error 1 So this is some sort of fallout from commit aa65de042f582896, which invented that as a generated file. Perhaps the solution is to extend src/test/regress/GNUmakefile to know about this file explicitly (as it already does know about src/port/pg_config_paths.h). But that seems rather brute-force; in particular it seems like that does nothing to keep us from getting burnt again the same way in future. I wonder if we should modify src/backend/Makefile so that it exposes a phony target for "update all the generated include files", and then have src/test/regress/GNUmakefile call that. Or maybe there are other ways. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers