From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bob Cochran <pgsql(at)mindchasers(dot)com> |
Cc: | pgsql-novice novice <pgsql-novice(at)postgresql(dot)org> |
Subject: | Re: initdb failing on REL9_5_STABLE with exit code 132... |
Date: | 2016-07-01 19:34:16 |
Message-ID: | 27049.1467401656@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Bob Cochran <pgsql(at)mindchasers(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bob Cochran | 2016-07-01 21:16:27 | Re: initdb failing on REL9_5_STABLE with exit code 132... |
Previous Message | Bob Cochran | 2016-07-01 15:53:03 | initdb failing on REL9_5_STABLE with exit code 132... |