"Luke Lonergan" <llonergan@xxxxxxxxxxxxx> writes: > On 4/7/06 3:27 PM, "Gavin Hamill" <gdh@xxxxxxxxxxxxx> wrote: >> 278774: __semop(15728650, 0x0FFFFFFFFFFF7E80, 1) = 0 >> 155712: __semop(15728650, 0x0FFFFFFFFFFF5920, 1) = 0 >> 278774: __semop(15728649, 0x0FFFFFFFFFFF6F10, 1) > Seems like you're hitting a very small target in RAM with these semop calls. IIRC the address passed to semop() in our code is always a local struct on the stack, so that's a bit of a red herring --- there won't be cross-processor contention for that. It's plausible though that we are seeing contention across members of the LWLock array, with the semop storm just being a higher-level symptom of the real hardware-level problem. You might try increasing LWLOCK_PADDED_SIZE to 64 or even 128, see src/backend/storage/lmgr/lwlock.c (this is something that does exist in 8.1, so it'd be easy to try). regards, tom lane
