Thread: Postgres 8.4 segfaults on CentOS 5.5 (using EnterpriseDB installers)

Postgres 8.4 segfaults on CentOS 5.5 (using EnterpriseDB installers)

From
Aleksey Tsalolikhin
Date:
Hi.

   We've been running PostgreSQL 8.4.2 on CentOS 5.4 (64-bit),
installed with the EnterpriseDB installer.  This has been excellent.

   Now we have our first CentOS 5.5 server (64-bit) and I installed
PostgreSQL 8.4.4 using the EnterpriseDB installer, and it is unable to
start the database instance.  If I try to start it manually, I get a
Segmentation Fault.  I tried the 8.4.2 installer, but the installed
binaries segfault too.  Have you seen this?  Any suggestions to
resolve it?

  My /var/log/messages contains this after I try to run "psql" or
"pg_ctl" (after 8.4.2 install):

Jun  4 18:12:07 hwd-ddc-fox-prod01 kernel: psql[14072]: segfault at
0000000000000008 rip 000000372340a402 rsp 00007fffc0b2b940 error 4

Jun  4 18:22:53 hwd-ddc-fox-prod01 kernel: pg_ctl[14163]: segfault at
0000000000000008 rip 000000372340a402 rsp 00007fff8d14f040 error 4


Here is an strace:

open("/opt/PostgreSQL/8.4/bin/../lib/libsepol.so.1", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/lib64/libsepol.so.1", O_RDONLY)  = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@=\0%7\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=247496, ...}) = 0
mmap(0x3725000000, 2383168, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3725000000
mprotect(0x372503b000, 2097152, PROT_NONE) = 0
mmap(0x372523b000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3b000) = 0x372523b000
mmap(0x372523c000, 40256, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x372523c000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2abeb4a36000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2abeb4a37000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2abeb4a38000
arch_prctl(ARCH_SET_FS, 0x2abeb4a37960) = 0
mprotect(0x372a211000, 4096, PROT_READ) = 0
mprotect(0x3724615000, 4096, PROT_READ) = 0
mprotect(0x3723b4d000, 16384, PROT_READ) = 0
mprotect(0x3724281000, 4096, PROT_READ) = 0
mprotect(0x3723e02000, 4096, PROT_READ) = 0
mprotect(0x3737008000, 4096, PROT_READ) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++


I tried turning off SELinux but still get the Segmentation Fault.

Any suggestions, please?

Best,
-at

Re: Postgres 8.4 segfaults on CentOS 5.5 (using EnterpriseDB installers)

From
Steve Crawford
Date:
On 06/04/2010 06:28 PM, Aleksey Tsalolikhin wrote:
> Hi.
>
>   ...
>     Now we have our first CentOS 5.5 server (64-bit) and I installed
> PostgreSQL 8.4.4 using the EnterpriseDB installer, and it is unable to
> start the database instance.  If I try to start it manually, I get a
> Segmentation Fault.  I tried the 8.4.2 installer, but the installed
> binaries segfault too.  Have you seen this?  Any suggestions to
> resolve it?
>
> ...
>
> Any suggestions, please?
>
>
Since it doesn't look like anyone has jumped in with ideas I'll take
some shots in the dark. I haven't seen this issue come up before and
CentOS lags RHEL and is supposed to be basically binary-identical so I
suspect it is related something about your particular install.

Is it possible that you (perhaps as a dependency) have some parts of
PostgreSQL installed by CentOS and are experiencing conflicts.

I would both verify that you really have disabled SELinux and also try
removing all traces of all installed copy/copies of PG and installing
the (now version 8.4) PostgreSQL installation from the CentOS 5.5
distribution and see if that works then go from there.

Cheers,
Steve

Re: Postgres 8.4 segfaults on CentOS 5.5 (using EnterpriseDB installers)

From
Aleksey Tsalolikhin
Date:
Dear Steve,

  Thanks for your suggestions!

  I ended up switching from the Enterprise DB installer to the
Postgres PGDG84 YUM repository, since (a) it provides PostgreSQL 8.4.4
AND Slony 1.x (unlike Enterprise DB installer which only has
Slony 2.0.2 which has a potential data loss problem), and now
I can keep my entire configuration in RPM packages.

Thanks!
Aleksey