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

Chris Hanks <christopher.m.hanks@gmail.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@entry=0x7ffef442af00,
> collector=collector@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@entry=0x7ffef442af00,
> collector=collector@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