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