Re: Problems with 8.3 - Mailing list pgsql-general

From Alex Turner
Subject Re: Problems with 8.3
Date
Msg-id 33c6269f0803081012n7549b176m15fd612d162b41b0@mail.gmail.com
Whole thread Raw
In response to Re: Problems with 8.3  ("Douglas McNaught" <doug@mcnaught.org>)
Responses Re: Problems with 8.3  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Sat, Mar 8, 2008 at 1:05 PM, Douglas McNaught <doug@mcnaught.org> wrote:
> On 3/8/08, Alex Turner <armtuk@gmail.com> wrote:
>
> > No I'm not.  Where would a core file be if there was going to be one?
>
>  They should appear in the data directory (e.g. /var/lib/pgsql/data).
>

Yeah - thats where I was looking, so I'm guessing some where I don't
have ulimit set up right for the process :(.  My strace showed the
segfault right after loading distance.so which is my shared object
that contains my stored procs for that database, so I'm pretty sure it
was in there.  I found what was going on in that bit and fixed it so
it's not crashing anymore, I'm just worried about how on earth that
could have affected other back end processes that were querying
unrelated databases.

>
>  >  I'm not sure how I can tell if the ulimit applies to the running
>  >  postmaster
>  >
>  >  I am the postgres user and ulimit -a show unlimited for core, and I
>  >  run pg_ctl start.  I have put it in that one place in /etc/ and also
>  >  in ~/.bash_profile for postgres
>
>  That should work.  It would be nice to be able to see the limits for a
>  process through /proc, but unfortunately that's never been
>  implemented...
>

That would be nice. I wish there were more than 24 hours in a day so I
could scratch some of my proverbial itches like that.

>  -Doug
>

pgsql-general by date:

Previous
From: "Douglas McNaught"
Date:
Subject: Re: Problems with 8.3
Next
From: Colin Fox
Date:
Subject: Re: ER Diagram design tools (Linux)