Re: crash help, pgsql 7.2.1 on RH7.3

okay, argh, after messing around with /etc/security/limits.conf, it would
have been nice to know that limits.conf doesn't change the default ulimit
rather the limits of user ulimit changes! mean to say, pam_limits.so and
limits.conf do not change the default ulimit, just the bounds, so then the
user can ulimit -c unlimited. i expect regular user to never be able to
increase their ulimits - call me old fasioned... what's next, regular user
negative renice?!? anyways...

but, uh, what am i going to do with a core file? i would need a non-stripped
postgres binary first, right?

i checked out the cwd in /proc, it is /var/lib/pgsql (actally i symlinked it
into another fs) which is postgres:postgres mode 700.

----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Tim Lynch" <admin+pgsqladmin@thirdage.com>
Cc: <pgsql-admin@postgresql.org>
Sent: Wednesday, November 20, 2002 8:31 PM
Subject: Re: [ADMIN] crash help, pgsql 7.2.1 on RH7.3


: I said:
: > "Tim Lynch" <admin+pgsqladmin@thirdage.com> writes:
: >> i don't see a core file.
:
: > Check that you are starting the postmaster with "ulimit -c unlimited";
: > this is not the default on most Linuxen, so you may have to add that to
: > the start script.  Also note that the postmaster never does a chdir,
: > so if it drops core it will be in the same directory the start script
: > was running in.
:
: Drat, I forgot to mention an important corollary: make sure the
: postmaster is started in a directory that's writable by the postgres
: user, else you'll get no corefile.
:
: (For completeness I'll mention here that when individual backends dump
: core, it's in the $PGDATA/base/nnn/ directory of the database they're
: connected to.  So you can easily distinguish a postmaster core from
: a backend core, just by where it was dropped.)
:
: regards, tom lane
: