Re: initdb failing on REL9_5_STABLE with exit code 132...
От | Tom Lane |
---|---|
Тема | Re: initdb failing on REL9_5_STABLE with exit code 132... |
Дата | |
Msg-id | 27049.1467401656@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | initdb failing on REL9_5_STABLE with exit code 132... (Bob Cochran <pgsql@mindchasers.com>) |
Ответы |
Re: initdb failing on REL9_5_STABLE with exit code 132...
|
Список | pgsql-novice |
Bob Cochran <pgsql@mindchasers.com> writes: > I just built REL9_5_STABLE using an embedded Linux install 4.1.8. > I configured as follows: configure --with-python --with-openssl > --enable-debug > When I run initdb, I get the following: > creating subdirectories ... ok > selecting default max_connections ... 100 > selecting default shared_buffers ... 128MB > selecting dynamic shared memory implementation ... posix > creating configuration files ... ok > creating template1 database in /usr/local/pgsql/data/base/1 ... ok > initializing pg_authid ... ok > initializing dependencies ... ok > creating system views ... ok > loading system objects' descriptions ... sh: line 1: 19593 Illegal > instruction "/usr/local/pgsql/bin/postgres" --single -F -O -c > search_path=pg_catalog -c exit_on_error=true template1 > /dev/null > child process exited with exit code 132 Hm, not much to go on there. In the past, when we've seen crashes at this stage, it's frequently meant a compiler bug or at least over- aggressive optimization. If you're using a bleeding-edge compiler it might be worth backing off the -O level to see what happens. regards, tom lane
В списке pgsql-novice по дате отправления: