On Wed, Dec 15, 2010 at 6:07 AM, Peter Geoghegan <peter.geoghega...@gmail.com> wrote: > On 15 December 2010 01:35, Robert Haas <robertmh...@gmail.com> wrote: >> I am suspicious of the fact that you are invoking initdb as ./initdb. >> Is it possible you're invoking this from the build tree, and there's >> an installed copy out there that doesn't match, but is getting used? >> Like maybe in /usr/local/pgsql/bin? > > No, I'm not doing that. I'm running initdb from /usr/local/pgsql/bin > (nothing pg related can be found in my $PATH), but it's the only copy > on my system, which was installed from git master last night. It has > debugging symbols, and I've actually re-created this from initdb's > point of view within GDB with source level debugging.
Well, something's clearly funky here because your initdb has debugging symbols but your postgres executable does not. I may be missing something obvious, but I don't see how that can happen without mixing up two different builds. >> Can you fire up gdb on this core dump, using "gdb >> /usr/local/pgsql/bin/postgres /path/to/coredump"? Or, another >> possibility is to run initdb with --noclean and then run the command, >> without routing the output to /dev/null: >> >> /usr/local/pgsql/bin/postgres" --single -F -O -c >> search_path=pg_catalog -c exit_on_error=true template1 > > I cannot find the coredump. Perhaps it's a permissions issue. What do you > think? It would presumably get dumped into the data directory. So if --noclean isn't used I expect it'll get nuked. > Anyway, I have produced a useful backtrace by debugging postgres > directly after running initdb with --noclean as described: > > [pe...@peter bin]$ /usr/local/pgsql/bin/postgres --single -F -O -c > search_path=pg_catalog -c exit_on_error=true template1 > Segmentation fault > [pe...@peter bin]$ gdb postgres > GNU gdb (GDB) Fedora (7.2-26.fc14) > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from /usr/local/pgsql/bin/postgres...done. > (gdb) set args --single -F -O -c search_path=pg_catalog -c > exit_on_error=true template1 > (gdb) start > Temporary breakpoint 1 at 0x577360 > Starting program: /usr/local/pgsql/bin/postgres --single -F -O -c > search_path=pg_catalog -c exit_on_error=true template1 > > Temporary breakpoint 1, 0x0000000000577360 in main () > (gdb) c > Continuing. > > Program received signal SIGSEGV, Segmentation fault. > 0x000000000047615b in _bt_preprocess_keys () > (gdb) bt > #0 0x000000000047615b in _bt_preprocess_keys () > #1 0x0000000000475382 in _bt_first () > #2 0x0000000000473d71 in btgettuple () > #3 0x00000000006ba67c in FunctionCall2 () > #4 0x000000000046e08a in index_getnext () > #5 0x000000000046d556 in systable_getnext () > #6 0x00000000006a92bf in LookupOpclassInfo () > #7 0x00000000006a9a58 in RelationInitIndexAccessInfo () > #8 0x00000000006aa9cb in RelationBuildDesc () > #9 0x00000000006aabfd in load_critical_index () > #10 0x00000000006ac12a in RelationCacheInitializePhase3 () > #11 0x00000000006c19ca in InitPostgres () > #12 0x000000000060058f in PostgresMain () > #13 0x000000000057774d in main () Ugh. Maybe someone smarter can figure out what that means, but I have no clue. _bt_preprocess_keys() is a pretty good-sized function; there's no obvious way to know which pointer reference is blowing up without line-number information. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers