amacvar kahitarich-postgresfo...@yahoo.com writes:
In addition here is a backtrace of the process while it hung again today:
(thanks to our SA Eric)
#0 0x00396c8d4627 in semop () from /lib64/libc.so.6
#1 0x005dc313 in PGSemaphoreLock ()
#2 0x00616586 in LWLockAcquire ()
#3 0x004a718c in ginHeapTupleFastInsert ()
#4 0x0049c808 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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
