Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125])
	by mail.postgresql.org (Postfix) with ESMTP id E8E12F6332A
	for <pgsql-general@postgresql.org>;
	Thu, 19 Jul 2012 03:34:36 -0300 (ADT)
Received: from mail-pb0-f46.google.com ([209.85.160.46])
	by makus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <ringerc@ringerc.id.au>) id 1SrkJm-0005W2-On
	for pgsql-general@postgresql.org; Thu, 19 Jul 2012 06:34:35 +0000
Received: by pbbrp8 with SMTP id rp8so3875425pbb.19
	for <pgsql-general@postgresql.org>;
	Wed, 18 Jul 2012 23:34:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:x-gm-message-state;
	bh=rjM3YJpGXfrWNtj1u2gOBmAi2zJLryUaH1Z+gvuA7so=;
	b=CPz3G+/kVfPmanoFJ94HeAYf2P/XmSkVLEAmWaDQE+Wv3hnG13DGmJ1HrvIDVqqoaU
	JZKSK/AZeajXjA50Biod8Rivii3mWANZrnpawTTxTZVm4qBO7xhzynNYGoEdYWH08sV5
	jUZfWe8hIWTPch1xrQNLIoJvLsMkHu2AW11d11VGmYYIJtp8fO3Z5ejKOpvubdwPW7EZ
	yN02meiq9LMQoGsIxkT2Gr0X8hU214Ky8O3aq/uLPcNd3t9Eg7pHT2XgfKRhthOPms75
	9BpCDolOZUjWTNMVcI5u2sbee8zPgqkrRxGTAByF4+goEEMFH2d+R9OQn9E929sgytDv
	qTPA==
Received: by 10.68.116.203 with SMTP id jy11mr2520335pbb.129.1342679661271;
	Wed, 18 Jul 2012 23:34:21 -0700 (PDT)
Received: from ayaki.localdomain (office1.postnewspapers.com.au.
	[150.101.171.128])
	by mx.google.com with ESMTPS id sh3sm1170762pbc.16.2012.07.18.23.34.18
	(version=SSLv3 cipher=OTHER); Wed, 18 Jul 2012 23:34:20 -0700 (PDT)
Message-ID: <5007AA67.1000808@ringerc.id.au>
Date: Thu, 19 Jul 2012 14:34:15 +0800
From: Craig Ringer <ringerc@ringerc.id.au>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Amod Pandey <amod.pandey@zovi.com>
CC: pgsql-general@postgresql.org
Subject: Re: Segmentation fault
References: 
 <CAAxoy_LDza-pxexgDUF7KhJmnb+5d=W7z6-DP1O7i_CS=8dDzw@mail.gmail.com>
	<50078411.9030602@ringerc.id.au>
	<CAAxoy_+Mahu4QK8YXi0KW7u+UZo8kEZLxfipHcDFZz1mbVqGEQ@mail.gmail.com>
In-Reply-To: 
 <CAAxoy_+Mahu4QK8YXi0KW7u+UZo8kEZLxfipHcDFZz1mbVqGEQ@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------070209060301060602070201"
X-Gm-Message-State: 
 ALoCoQnbJAQyUbvFCeoTiUoo01VvOgUT1ZQLmxb4haOULhE9jvIpmJ4ZS21uR+mpVf2RyGBlMFNT
X-Pg-Spam-Score: -1.9 (-)
X-Archive-Number: 201207/356
X-Sequence-Number: 188867

This is a multi-part message in MIME format.
--------------070209060301060602070201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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


--------------070209060301060602070201
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 07/19/2012 01:52 PM, Amod Pandey
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAAxoy_+Mahu4QK8YXi0KW7u+UZo8kEZLxfipHcDFZz1mbVqGEQ@mail.gmail.com"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html;
        charset=ISO-8859-1">
      Thank you Craig for explaining in such a detail. I am adding more
      information and would see what more I can add,<br>
      <br>
      $ulimit -a<br>
      core file size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (blocks, -c) 0<br>
      <br>
      So I assume there to be no core dump file.<br>
    </blockquote>
    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.<br>
    <br>
    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.<br>
    <br>
    <blockquote
cite="mid:CAAxoy_+Mahu4QK8YXi0KW7u+UZo8kEZLxfipHcDFZz1mbVqGEQ@mail.gmail.com"
      type="cite">
      <br>
      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.<br>
    </blockquote>
    You would need to put this command in the PostgreSQL startup scripts
    *then* restart PostgreSQL.<br>
    <br>
    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 &lt;distro&gt;" or "change ulimit &lt;distro&gt;"
    for example.<br>
    <br>
    <blockquote
cite="mid:CAAxoy_+Mahu4QK8YXi0KW7u+UZo8kEZLxfipHcDFZz1mbVqGEQ@mail.gmail.com"
      type="cite"><br>
      Linux distros<br>
      -------------------<br>
      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<br>
      <br>
    </blockquote>
    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.<br>
    <br>
    --<br>
    Craig Ringer<br>
    <br>
  </body>
</html>

--------------070209060301060602070201--