Here's the output I see when $SUBJECT occurs, on a pg freshly built
from git master with --enable-debug and --enable-cassert:
[postgres@peter bin]$ uname -a
Linux peter.laptop 2.6.35.9-64.fc14.x86_64 #1 SMP Fri Dec 3 12:19:41
UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
[postgres@peter bin]$ ./initdb -D /var/lib/pgsql/data
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 en_IE.utf8.
The default database encoding has accordingly been set to UTF8.
The default text search configuration will be set to "english".
fixing permissions on existing directory /var/lib/pgsql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 24MB
creating configuration files ... ok
creating template1 database in /var/lib/pgsql/data/base/1 ... ok
initializing pg_authid ... sh: line 1: 23515 Segmentation fault
(core dumped) "/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 139
initdb: removing contents of data directory "/var/lib/pgsql/data"
I'm having difficulty producing a useful backtrace, because the
segfault seemingly doesn't actually occur within initdb - it occurs
within a postgres process. If someone could tell me the trick to
attaching to that process under these circumstances, I could look into
it further.
The trouble seems occur here, at line 1224 of initdb.c:
for (line = pg_authid_setup; *line != NULL; line++) PG_CMD_PUTS(*line);
After I see the segmentation fault in stderr, gdb reports that initdb
has received SIGPIPE.
Hope that helps.
--
Regards,
Peter Geoghegan
