Message-ID: <4FD6F271.5030905@ringerc.id.au>
Date: Tue, 12 Jun 2012 15:40:33 +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: Benson Jin <benson.jin@troo.com>
CC: pgsql-general@postgresql.org
Subject: Re: Segmentation Fault
References: <299885816.271173.1339442120437.JavaMail.root@troo.com>
In-Reply-To: <299885816.271173.1339442120437.JavaMail.root@troo.com>
Content-Type: multipart/alternative;
	boundary="------------030504040309010400010603"

This is a multi-part message in MIME format.
--------------030504040309010400010603
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 06/12/2012 03:15 AM, Benson Jin wrote:
> Hi All,
>
> A silly question.... how do I get install external symbols for 
> postgresql, if compiled it myself previously? Do I recompile it with 
> --enable-debug option?

If you didn't strip the executable then the cores produced even without 
--enable-debug will be somewhat useful, but debug info is ideal. You 
could try that first, since it'll give you a chance to make sure you can 
at least get and analyse a core file before spending time recompiling 
and reinstalling Pg.

Recompiling with --enable-debug is the easy way to get executables with 
debug info embedded in them. If the installed libraries, etc haven't 
changed since compiling your original copy of PostgreSQL, and if you're 
compiling the EXACT same source code, you can debug the core against 
these executables without replacing the ones you're actually running. 
Something like a libc upgrade since the original copies were built might 
mean that the new debug executables are no longer exactly compatible 
with the ones your core file came from, though, so the results can't be 
totally trusted.

Ideally you want to run the debug executables and get the core to debug 
from them. An --enable-debug build on gcc will still be optimised and 
should have no detectable performance difference. The executables are 
huge, but the ELF sections containing the debug info never get mapped 
in, so it doesn't actually matter.

An alternative is to build with --enable-debug, strip the debug info 
into external symbols packages using "strip --only-keep-debug". There 
isn't much point unless disk space consumed by executables is a big 
concern, though.

I always use --enable-debug when building Pg. I rarely need the symbols, 
but it's handy to have them when I do.

--
Craig Ringer

--------------030504040309010400010603
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 06/12/2012 03:15 AM, Benson Jin
      wrote:<br>
    </div>
    <blockquote
      cite="mid:299885816.271173.1339442120437.JavaMail.root@troo.com"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html; charset=utf-8">
      <div>Hi All,
        <div><br>
        </div>
        <div>A silly question.... how do I get install external symbols
          for postgresql, if compiled it myself previously? Do I
          recompile it with --enable-debug option?<br>
        </div>
      </div>
    </blockquote>
    <br>
    If you didn't strip the executable then the cores produced even
    without --enable-debug will be somewhat useful, but debug info is
    ideal. You could try that first, since it'll give you a chance to
    make sure you can at least get and analyse a core file before
    spending time recompiling and reinstalling Pg.<br>
    <br>
    Recompiling with --enable-debug is the easy way to get executables
    with debug info embedded in them. If the installed libraries, etc
    haven't changed since compiling your original copy of PostgreSQL,
    and if you're compiling the EXACT same source code, you can debug
    the core against these executables without replacing the ones you're
    actually running. Something like a libc upgrade since the original
    copies were built might mean that the new debug executables are no
    longer exactly compatible with the ones your core file came from,
    though, so the results can't be totally trusted.<br>
    <br>
    Ideally you want to run the debug executables and get the core to
    debug from them. An --enable-debug build on gcc will still be
    optimised and should have no detectable performance difference. The
    executables are huge, but the ELF sections containing the debug info
    never get mapped in, so it doesn't actually matter.<br>
    <br>
    An alternative is to build with --enable-debug, strip the debug info
    into external symbols packages using "strip --only-keep-debug".
    There isn't much point unless disk space consumed by executables is
    a big concern, though.<br>
    <br>
    I always use --enable-debug when building Pg. I rarely need the
    symbols, but it's handy to have them when I do.<br>
    <br>
    --<br>
    Craig Ringer<br>
  </body>
</html>

--------------030504040309010400010603--