Re: BUG #5736: 9.0.1 segmentation fault (sig11) during long-lived update - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #5736: 9.0.1 segmentation fault (sig11) during long-lived update
Date
Msg-id 23040.1288471381@sss.pgh.pa.us
Whole thread Raw
In response to BUG #5736: 9.0.1 segmentation fault (sig11) during long-lived update  ("Henry" <henka@cityweb.co.za>)
Responses Re: BUG #5736: 9.0.1 segmentation fault (sig11) during long-lived update  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Re: BUG #5736: 9.0.1 segmentation fault (sig11) during long-lived update  ("Henry C." <henka@cityweb.co.za>)
List pgsql-bugs
"Henry" <henka@cityweb.co.za> writes:
> Before I run this again, what's the best way to proceed to get a core dump
> so I can run a gdb backtrace to provide more info?  Simply 'ulimit -c
> 5242880' as user postgres and restart PG?

I'd use "ulimit -c unlimited", myself, rather than making arbitrary
assumptions about how big the corefile might be.

Also, make sure the ulimit command is effective in the shell that will
actually launch the postmaster.  This can be tricky if your PG launch
script uses "su".  If you're using the RH or PGDG RPMs' initscript,
I'd suggest putting the ulimit command in ~postgres/.bash_profile.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Greg Stark
Date:
Subject: Re: BUG #5732: parsing of: "WHERE mycol=123AND ..."
Next
From: Arturas Mazeika
Date:
Subject: Re: BUG #5735: pg_upgrade thinks that it did not start the old server