Thank you Craig for explaining in such a detail. I am adding more information and would see what more I can add,
$ulimit -a
core file size (blocks, -c) 0
So I assume there to be no core dump file.
If I set 'ulimit -c unlimited' will it generate core dump if there is another occurrence. Do I need to restart postgres for this to take effect.
Linux distros
-------------------
Linux ip-xx-xx-xx-xx 2.6.35.11-83.9.amzn1.x86_64 #1 SMP Sat Feb 19 23:42:04 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
I will see if there are queries which I can share.
Regards
Amod
On Thu, Jul 19, 2012 at 9:20 AM, Craig Ringer
<ringerc@ringerc.id.au> wrote:
On 07/19/2012 12:37 AM, Amod Pandey wrote:
Server stopped due to Segmentation Fault. Server was running successfully for an year.
PostgreSQL: 9.0.3
from /var/log/messages
Jul 18 19:00:03 ip-10-136-22-193 kernel: [18643442.660032] postgres[6818]: segfault at 170a8c6f ip 000000000044c94d sp 00007fff9fee5b80 error 4 in postgres[400000+495000]
from pg log
LOG: server process (PID 6818) was terminated by signal 11: Segmentation fault
LOG: terminating any other active server processes
Please suggest if there is a way to find out the issue.
Did the crash produce a core file ?
You haven't mentioned what Linux distro or kernel version you're on, and defaults vary. Look in your PostgreSQL datadir and see if there are any files with "core" in the name.
Unfortunately most Linux distros default to not producing core files. Without a core file it'll be nearly impossible because the segfault message reported by the kernel only contains the instruction pointer and stack pointer. The stack pointer is invalid and useless without a core file, and with address space layout randomisation active the instruction pointer offsets are all randomised for each execution, so the ip doesn't tell you much on ASLR systems either.
If you can show more of the PostgreSQL logs from around the incident that would possibly be helpful.
--
Craig Ringer