Bug 19199
| Summary: | Postgresql Won't start on Alpha | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Dale Lovelace <dale> |
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Dale Lovelace <dale> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.3 | CC: | fweimer, msw |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | alpha | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2000-10-30 16:04:35 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Dale Lovelace
2000-10-16 19:45:17 UTC
Matt, any ideas? Initially I thought this was a problem with thhe IPC shared memory pools on the
various architcures for linux are not identical.
Eg for i386 it's 32Mb but only 4Mb for Alpha
[root@i386 /root]# cat /proc/sys/kernel/shmmax
33554432
[root@Alpha /root]# cat /proc/sys/kernel/shmmax
4169728
This is not the case.
When running the prgram through strace we can clearly see the culprit being the
call to semctl()
which fails (ERANGE) This is what the man page has to say on the subject.
ERANGE The argument cmd has value SETALL or SETVAL and
the value to which semval has to be set (for
some semaphore of the set) is less than 0 or
greater than the implementation value SEMVMX.
(relevant portion of the strace output)
semget(5432014, 0, 0) = -1 ENOENT (No such file or directory)
semget(5432014, 16, IPC_CREAT|0x180|0600) = 4096
semctl(4096, 0, SETALL, 0x11ffff1c0) = -1 ERANGE (Numerical result out of
range)
where the semctl call is
int semctl (int semid, int semnum, int cmd, union semun arg)
Unfortunately it's going to be extremely difficult to wade into
a) the postgres code
b) the libc code
c) the kernel
which this call seems to have scope in.
The actual moment of death comes into play from
src/backend/storage/lmgr/proc.c:162
leading into the actual call in
src/backend/storage/ipc/ipc.c:318 (runs in from line 294)
Now I have a problem here because gdb is for some odd reason not letting me view
the structure thats being used in the call.
I personally can't progress further than this unless someone has come intresting
ideas of how to get around the gdb problem I'm having (note: I don't use gdb
that much)
I have to leave this one open
But at least chased down to a point that someone else can follow on from
Phil
=--=
We think it's a glibc issue, and Jakub has hopefully fixed it. glibc building now, will build postgresql later. *** Bug 19327 has been marked as a duplicate of this bug. *** Filing bug against glibc glibc-2.1.95-2 should fix this (at least the stripped down testcase works). |