Jakub Ouhrabka wrote: > We've tried several times to get stacktrace from some of the running > backends during spikes, we got always this: > > 0x00002b005d00a9a9 in semop () from /lib/libc.so.6 > #0 0x00002b005d00a9a9 in semop () from /lib/libc.so.6 > #1 0x000000000054fe53 in PGSemaphoreLock (sema=0x2b00a04e5090, > interruptOK=0 '\0') at pg_sema.c:411 > #2 0x0000000000575d95 in LWLockAcquire (lockid=SInvalLock, > mode=LW_EXCLUSIVE) at lwlock.c:455 > #3 0x000000000056fbfe in ReceiveSharedInvalidMessages > (invalFunction=0x5e9a30 <LocalExecuteInvalidationMessage>, > resetFunction=0x5e9df0 <InvalidateSystemCaches>) at sinval.c:159 > #4 0x0000000000463505 in StartTransactionCommand () at xact.c:1439 > #5 0x000000000056fa4b in ProcessCatchupEvent () at sinval.c:347 > #6 0x000000000056fb20 in CatchupInterruptHandler > (postgres_signal_arg=<value optimized out>) at sinval.c:221 > #7 0x00002b005cf6f110 in killpg () from /lib/libc.so.6 > #8 0x0000000000000000 in ?? () Perhaps it would make sense to try to take the "fast path" in SIDelExpiredDataEntries with only a shared lock rather than exclusive. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
