"Marc G. Fournier" <scrappy@postgresql.org> writes:
> 'k, try this one ... looks better, actually has semget() calls in it :)
OK, here's our problem:
84250: semget(0x52e2c1,0x11,0x780) ERR#17 'File exists'
This is InternalIpcSemaphoreCreate failing because of key collision.
As it should.
84250: semget(0x52e2c1,0x11,0x0) = 1114112 (0x110000)
This is IpcSemaphoreCreate trying to see what's up. OK.
84250: __semctl(0x110000,0x10,0x5,0x0) = 537 (0x219)
IpcSemaphoreGetValue indicates it has the right "magic number" to be
a Postgres semaphore set. Still expected.
84250: __semctl(0x110000,0x10,0x4,0x0) = 83699 (0x146f3)
IpcSemaphoreGetLastPID says the sema set is last touched by pid 83699.
Looks reasonable (but do you want to double check that that matched the
first postmaster's PID?)
84250: getpid() = 84250 (0x1491a)
our pid ... as expected ...
84250: kill(0x146f3,0x0) ERR#3 'No such process'
Oops. Here is the problem: kill() is lying by claiming there is no such
process as 83699. It looks to me like there in fact is such a process,
but it's in a different jail.
I venture that FBSD 6 has decided to return ESRCH (no such process)
where FBSD 4 returned some other error that acknowledged that the
process did exist (EPERM would be a reasonable guess).
If this is the story, then FBSD have broken their system and must revert
their change. They do not have kernel behavior that totally hides the
existence of the other process, and therefore having some calls that
pretend it's not there is simply inconsistent.
regards, tom lane
