Re: recovery after segmentation fault

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it>, pgsql-general(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: recovery after segmentation fault
Date: 2009-04-08 23:38:10
Message-ID: 49DD3562.4060107@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Martijn van Oosterhout wrote:
> On Wed, Apr 08, 2009 at 05:24:08PM +0200, Ivan Sergio Borgonovo wrote:
>> How on Debian?
>> Debian does all it's automagic stuff in init. I never learned how to
>> start pg manually.
>
> What might be easier is turning on core dumps (ulimit -S -c unlimited)
> and then start postgres and see if it drops a core dump, which you can
> then feed to gdb.

Note that ulimit is inherited by child processes; it doesn't apply
system wide. You'll need to set the ulimit somewhere like the postgresql
init script, where the postmaster is a child of the shell in which the
ulimit command is run.

Also, because Debian strips its binaries by default, you might need to
rebuild the postgresql packages with debugging enabled and without
stripping to get a useful backtrace. Worth a try anyway, though.

Does Debian have a repository full of debug symbol packages like Ubuntu
does?

--
Craig Ringer

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Leif B. Kristensen 2009-04-08 23:57:04 Re: Are there performance advantages in storing bulky field in separate table?
Previous Message Ivan Sergio Borgonovo 2009-04-08 23:15:57 Re: recovery after segmentation fault