Marko Tiikkaja wrote:
> On 1/8/14 3:24 PM, I wrote:
> >
> >libc6-dbg only changed it a bit:
>
> Oops, looks like there was something wonky about that dump. This
> should make more sense:
>
> #0 0x00007f26dd17d5b7 in semop () from /lib/x86_64-linux-gnu/libc.so.6
> #1 0x00000000005f6128 in PGSemaphoreLock (sema=0x7f26d79e5c80,
> interruptOK=0 '\000') at pg_sema.c:418
> #2 0x00000000006359c5 in LWLockAcquire (lockid=87, mode=LW_SHARED)
> at /build/buildd/postgresql-9.1-9.1.9/build/../src/backend/storage/lmgr/lwlock.c:464
> #3 0x000000000049fabb in SimpleLruWaitIO (slotno=6, ctl=<optimized
> out>) at /build/buildd/postgresql-9.1-9.1.9/build/../src/backend/access/transam/slru.c:306
Yeah, this makes a lot more sense. What this is saying is that it's
waiting for the I/O-lock on the pg_clog page to be released. In other
words there is some other process holding that lock, which is supposed
to be reading the page, but for some reason it's failing to do that
timely. I guess you would need to get backtraces from all processes to
see which one differs (i.e. which one has the lock and is trying to do
something but not doing it).
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
