On Tue, Oct 22, 2013 at 10:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
Well, geez. That's obnoxious. I understand that an unimplemented
system call might return ENOSYS, but SIGSYS seems pretty unfriendly.
Why put the wrapper in your system libraries at all if it's just going
to kill the process?
I don't think a configure-time test is a good idea because there's no
guarantee that the configure-time machine and the run-time machine
have the same behavior. But having initdb fork a child process to run
the test seems like a reasonable way forward, even though I feel like
it shouldn't really be needed. One possibly unfortunate things is
that SIGSYS at least on my box normally produces a core dump, so the
initdb child might leave behind a core file somewhere as a side
effect. Not sure if we can or want to work around that somehow.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
