Re: PostgreSQL 9.2.4 + CentOS 6.5 64 bit - segfault error in initdb

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bhushan Pathak <bhushan(dot)pathak02(at)gmail(dot)com>
Cc: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: PostgreSQL 9.2.4 + CentOS 6.5 64 bit - segfault error in initdb
Date: 2014-06-06 14:39:43
Message-ID: 3793.1402065583@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Bhushan Pathak <bhushan(dot)pathak02(at)gmail(dot)com> writes:
>>> Stopping postgresql service: [ OK ]
>>> Starting postgresql service: [FAILED]
>>>
>>> pgstartup log has the same line -
>>> Segmentation fault (core dumped)
>>>
>>> Where is this core dump file generated? How do we proceed further from
>>> here?

FWIW, I'd expect any such core to be generated either in postgres'
home directory or the $PGDATA directory, depending on what is
failing when. If you don't see a core, it's likely because the failing
program is running under "ulimit -c 0", which is the default environment
for daemons (for security reasons). Try adding "ulimit -c unlimited"
to the start script and/or the postgres user's ~/.bash_profile to see
if you can get a core file for debugging.

The issue seems like it must trace back to some difference in the
normal shell environment of the postgres user versus the environment
set up by "service" ... but it's not clear yet what that difference
is.

Also, it's not very clear whether you're trying to use the Red Hat/CentOS
packaging of PG, or the PGDG packaging. As Adrian alluded to, those are
not terribly compatible --- if you've got fragments of both laying about,
that could be causing issues.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Stefan Froehlich 2014-06-06 14:57:10 Re: interpret bytea output as text / double encode()
Previous Message Tom Lane 2014-06-06 14:30:56 Re: interpret bytea output as text / double encode()