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
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 |