Does anybody care about being able to compile ipc_test as a standalone
binary any more?
I ask because, while working on some of the outstanding cleanup issues
around dynamic shared memory, I made sure to test whether it required
further adjustments based on the changes that I'd done, only to
discover that it was already broken by the huge pages patch:
[rhaas pgsql]$ make -C src/backend/port ipc_test
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv -g -Wall -Werror -L../../../src/port -L../../../src/common
-L/opt/local/lib -Wl,-dead_strip_dylibs -Wall -Werror ipc_test.o
pg_sema.o pg_shmem.o -lpgcommon -lpgport -lintl -lxml2 -lssl -lcrypto
-lz -lreadline -lm -o ipc_test
Undefined symbols for architecture x86_64:
"_huge_pages", referenced from:
_PGSharedMemoryCreate in pg_shmem.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make: *** [ipc_test] Error 1
My judgement is that ipc_test has insufficient utility to justify
keeping it around and updating it every time sysv_shmem.c references a
new symbol or experiences a relevant calling signature change. So I'd
favor just ripping it out. I doubt we're likely to have any
completely new semaphore or shared memory implementations that require
this kind of testing any time soon, and even if we do I think whoever
is doing it can quite easily put together a bespoke testing framework
that will likely serve their needs at least as well as ipc_test does.
It was probably quite reasonable to add this 12 years ago but I just
don't think we need it any more.
All that having been said, if somebody feels strongly that this is
still useful, I'd rather just fix it than argue about it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
