Re: PostgreSQL 9.2.4 + CentOS 6.5 64 bit - segfault error in initdb - Mailing list pgsql-general

From Tom Lane
Subject Re: PostgreSQL 9.2.4 + CentOS 6.5 64 bit - segfault error in initdb
Date
Msg-id 3793.1402065583@sss.pgh.pa.us
Whole thread Raw
In response to Re: PostgreSQL 9.2.4 + CentOS 6.5 64 bit - segfault error in initdb  (Bhushan Pathak <bhushan.pathak02@gmail.com>)
Responses Re: PostgreSQL 9.2.4 + CentOS 6.5 64 bit - segfault error in initdb
List pgsql-general
Bhushan Pathak <bhushan.pathak02@gmail.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


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: interpret bytea output as text / double encode()
Next
From: Stefan Froehlich
Date:
Subject: Re: interpret bytea output as text / double encode()