=?ISO-8859-15?Q?Torsten_Z=FChlsdorff?= <foo@meisterderspiele.de> writes:
> Core was generated by `postgres'.
> Program terminated with signal 12, Bad system call.
> Reading symbols from /lib/libm.so.5...done.
> Loaded symbols for /lib/libm.so.5
> Reading symbols from /lib/libc.so.7...done.
> Loaded symbols for /lib/libc.so.7
> Reading symbols from /libexec/ld-elf.so.1...done.
> Loaded symbols for /libexec/ld-elf.so.1
> #0 0x0000000800bb166c in shmctl () from /lib/libc.so.7
> (gdb) bt
> #0 0x0000000800bb166c in shmctl () from /lib/libc.so.7
> #1 0x00000000005b158f in PGSharedMemoryIsInUse (id1=Variable "id1" is
> not available.
> ) at pg_shmem.c:247
> #2 0x00000000006a0844 in CreateLockFile (filename=0x7ea036
> "postmaster.pid", amPostmaster=0 '\0', isDDLock=1 '\001',
> refName=0x800e0b180 "/usr/local/pgsql/data") at miscinit.c:835
> #3 0x000000000049baf0 in AuxiliaryProcessMain (argc=3,
> argv=0x7fffffffebc8) at bootstrap.c:350
> #4 0x000000000056742e in main (argc=4, argv=0x7fffffffebc0) at main.c:180
Well, this seems to be clear proof for what everyone suspected all
along: your kernel is rejecting SysV-shared-memory calls. I'm too tired
to go check that that shmctl() is the first such syscall during the boot
sequence, but it looks about right.
So we're now back to the question of *why* it's rejecting those calls,
when you apparently have the proper support configured. I'm afraid
you now need to seek the assistance of some FreeBSD kernel experts;
it's beyond the ken of a simple database hacker ...
regards, tom lane
