Re: Connections hang indefinitely while taking a LWLockTranche buffer_content lock.

Chris Hanks <christopher(dot)m(dot)hanks(at)gmail(dot)com> writes:
> Backtrace of query with PID 22:

> #0 0x00007fa23544ed87 in write_call_graph (fd=<optimized out>) at gmon.c:287
> #1 write_gmon () at gmon.c:394
> #2 0x00005639548bf72b in LWLockAcquire (lock=0xffff0001,
> mode=LW_EXCLUSIVE) at
> /build/postgresql-9.6-HEXeEe/postgresql-9.6-9.6.1/build/../src/backend/storage/lmgr/lwlock.c:1287
> #3 0x00005639546707c1 in ginHeapTupleFastInsert
> (ginstate=ginstate(at)entry=0x7ffef442af00,
> collector=collector(at)entry=0x7ffef442aee0)
> at /build/postgresql-9.6-HEXeEe/postgresql-9.6-9.6.1/build/../src/backend/access/gin/ginfast.c:314

> Backtrace of query with PID 16987

> #0 0x00007fa23544ed87 in write_call_graph (fd=<optimized out>) at gmon.c:287
> #1 write_gmon () at gmon.c:394
> #2 0x00005639548bf72b in LWLockAcquire (lock=0xffff000f,
> mode=LW_EXCLUSIVE) at
> /build/postgresql-9.6-HEXeEe/postgresql-9.6-9.6.1/build/../src/backend/storage/lmgr/lwlock.c:1287
> #3 0x00005639546704e0 in ginHeapTupleFastInsert
> (ginstate=ginstate(at)entry=0x7ffef442af00,
> collector=collector(at)entry=0x7ffef442aee0)

So it looks like ginHeapTupleFastInsert is doing something that carries a
risk of deadlocking on two or more LWLocks, if multiple processes try to
insert index entries concurrently. There's no deadlock detection in the
LWLock infrastructure --- that's one of the things that makes it
"lightweight" locks --- so callers have to avoid such coding patterns.

This is probably enough info for us to identify the exact cause. But
I don't have time to look right this minute, and am not the hacker most
familiar with the GIN infrastructure anyway. Anyone want to look for
the bug?

regards, tom lane