amacvar <kahitarich-postgresForum@xxxxxxxxx> writes: > In addition here is a backtrace of the process while it hung again today: > (thanks to our SA Eric) > #0 0x000000396c8d4627 in semop () from /lib64/libc.so.6 > #1 0x00000000005dc313 in PGSemaphoreLock () > #2 0x0000000000616586 in LWLockAcquire () > #3 0x00000000004a718c in ginHeapTupleFastInsert () > #4 0x000000000049c808 in gininsert () Interesting. The most plausible explanation I can see for this stack trace is that ginHeapTupleFastInsert is blocked trying to get buffer lock on one of the GIN index pages it locks directly --- either the metapage or the tail page of the fast-insert list. That would suggest a deadlock condition, that is somebody else trying to get the same two locks in the other order. (One of the ways that the LWLock mechanism is lightweight is that it has no deadlock detection, so if this is what's happening the deadlock would persist until you kill the processes.) However, if that's the case then there must be another process also blocked. Next time it happens, could you look around at *all* the postgres processes and collect stack traces from any that don't seem to be making progress? It doesn't appear to me that ginHeapTupleFastInsert itself is in the wrong here, so we need to find out what the conflicting process is doing. Also, as a temporary workaround, you might be able to dodge the problem by disabling the FASTUPDATE storage parameter for your GIN indexes. That won't help find the bug though, so if you could refrain from doing that until we've identified the cause, it'd be appreciated. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
