Thread: InitBufferPoolAccess crash
I have a 7.3.4 cluster that just sigsegv'd. I know an upgrade is desperately needed. In the meantime, does the following gdb output provide any clues as to what we might be able to do to nurse it along until we upgrade? Thanks, Ed PostgreSQL 7.3.4 on hppa2.0w-hp-hpux11.00, compiled by GCC gcc (GCC) 3.2.2 (gdb) core-file core Core was generated by `postgres'. Program terminated with signal 11, Segmentation fault. warning: The shared libraries were not privately mapped; setting a breakpoint in a shared library will not work until you rerun the program. (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...#0 0x12d288 in InitBufferPoolAccess () from /opt/pgsql/installs/postgresql-7.3.4/bin/postmaster (gdb) bt #0 0x12d288 in InitBufferPoolAccess () from /opt/pgsql/installs/postgresql-7.3.4/bin/postmaster Error accessing memory address 0x0: Invalid argument.
"Ed L." <pgsql@bluepolka.net> writes: > from /opt/pgsql/installs/postgresql-7.3.4/bin/postmaster > (gdb) bt > #0 0x12d288 in InitBufferPoolAccess () > from /opt/pgsql/installs/postgresql-7.3.4/bin/postmaster > Error accessing memory address 0x0: Invalid argument. Right offhand I'd imagine that the calloc() call failed and returned NULL --- leastwise it's hard to see how else that routine could crash. Could your machine be nearly out of memory? regards, tom lane
On Tuesday May 9 2006 3:07 pm, Tom Lane wrote: > "Ed L." <pgsql@bluepolka.net> writes: > > from /opt/pgsql/installs/postgresql-7.3.4/bin/postmaster > > (gdb) bt > > #0 0x12d288 in InitBufferPoolAccess () > > from /opt/pgsql/installs/postgresql-7.3.4/bin/postmaster > > Error accessing memory address 0x0: Invalid argument. > > Right offhand I'd imagine that the calloc() call failed and > returned NULL --- leastwise it's hard to see how else that > routine could crash. Could your machine be nearly out of > memory? Quite likely. It turns out we had a rogue spike of 1400 processes at that time, so that makes perfect sense. Thanks, Ed