Sigh, my old HPUX box is totally broken by DSM patch

initdb.c quoth:

* ... but the fact that a platform has shm_open
* doesn't guarantee that that call will succeed when attempted.

Indeed:

$ initdb
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "C".
The default database encoding has accordingly been set to "SQL_ASCII".
The default text search configuration will be set to "english".

Data page checksums are disabled.

creating directory /home/postgres/testversion/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... Bad system call(coredump)
$

gdb shows:

Core was generated by `initdb'.
Program terminated with signal 12, Bad system call.
(gdb) bt
#0 0xc0143fb0 in ?? () from /usr/lib/libc.1
#1 0xa890 in choose_dsm_implementation () at initdb.c:1098
#2 0xab10 in test_config_settings () at initdb.c:1217
#3 0xe310 in initialize_data_directory () at initdb.c:3412
#4 0xed0c in main (argc=1, argv=0x7b03ac68) at initdb.c:3691
#5 0xc0065784 in ?? () from /usr/lib/libc.1

I'm not entirely sure what to do about this. Conceivably we could have
initdb catch SIGSYS, but that seems rather ugly. Maybe configure needs a
run-time test to see if shm_open will work, rather than just probing to
see if such a function exists? I'm not thrilled with run-time tests in
configure though. Another possibility is for initdb to execute the
probe in a forked subprocess instead of risking doing it itself.

regards, tom lane