Re: Segmentation fault
От | Craig Ringer |
---|---|
Тема | Re: Segmentation fault |
Дата | |
Msg-id | 5007AA67.1000808@ringerc.id.au обсуждение исходный текст |
Ответ на | Segmentation fault (Amod Pandey <amod.pandey@zovi.com>) |
Список | pgsql-general |
On 07/19/2012 01:52 PM, Amod Pandey wrote:
Thank you Craig for explaining in such a detail. I am adding more information and would see what more I can add,Quite likely. Limits are inherited down process trees, so there's no guarantee that PostgreSQL's ulimit also prevented core file generation. However I haven't seen any distro configure a non-zero ulimit for PostgreSQL or other system services explicitly, so it's pretty darn likely to be zero, though.
$ulimit -a
core file size (blocks, -c) 0
So I assume there to be no core dump file.
Just check for a core file in the PostgreSQL data dir. If there is one, the Pg ulimit obviously wasn't zero. If there isn't, then given that Pg's working directory is always the datadir, chances are the ulimit prevented a core dump.
You would need to put this command in the PostgreSQL startup scripts *then* restart PostgreSQL.
If I set 'ulimit -c unlimited' will it generate core dump if there is another occurrence. Do I need to restart postgres for this to take effect.
It can be easier to configure it globally for the server. How to do this depends a bit on your distro and version; Google will help - "enable core dumps <distro>" or "change ulimit <distro>" for example.
Um, that's not a distro, that's a kernel. I'm assuming it's an Amazon cloud hosted machine by the kernel, and since Ubuntu (and IIRC Debian) puts its name in the uname version string it's probably RHEL/CentOS/Fedora.
Linux distros
-------------------
Linux ip-xx-xx-xx-xx 2.6.35.11-83.9.amzn1.x86_64 #1 SMP Sat Feb 19 23:42:04 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
--
Craig Ringer
В списке pgsql-general по дате отправления: