Re: Segmentation fault

From: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
To: Amod Pandey <amod(dot)pandey(at)zovi(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Segmentation fault
Date: 2012-07-19 06:34:15
Message-ID: 5007AA67.1000808@ringerc.id.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 07/19/2012 01:52 PM, Amod Pandey wrote:
> 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.
Quite likely. Limits are inherited down process trees, so there's no
guarantee that PostgreSQL's ulimit also prevented core file generation.
However I haven't seen any distro configure a non-zero ulimit for
PostgreSQL or other system services explicitly, so it's pretty darn
likely to be zero, though.

Just check for a core file in the PostgreSQL data dir. If there is one,
the Pg ulimit obviously wasn't zero. If there isn't, then given that
Pg's working directory is always the datadir, chances are the ulimit
prevented a core dump.

>
> 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.
You would need to put this command in the PostgreSQL startup scripts
*then* restart PostgreSQL.

It can be easier to configure it globally for the server. How to do this
depends a bit on your distro and version; Google will help - "enable
core dumps <distro>" or "change ulimit <distro>" for example.

>
> 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
>
Um, that's not a distro, that's a kernel. I'm assuming it's an Amazon
cloud hosted machine by the kernel, and since Ubuntu (and IIRC Debian)
puts its name in the uname version string it's probably RHEL/CentOS/Fedora.

--
Craig Ringer

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Alexander Law 2012-07-19 06:37:49 Re: main log encoding problem
Previous Message Sergey Konoplev 2012-07-19 06:03:24 Re: Problem running "ALTER TABLE...", ALTER TABLE waiting