I s this a bug of spgist index in a heavy write condition?

Hi,pgsql-hackers,

I'm not sure whether it is a bug of using spgist index or not .

OS Version:
CentOS release 6.2 (Final)

PostgreSQL Version:
postgres=# select version();
version
--------------------------------------------------------------------------------------------------------------
PostgreSQL 9.2.2 on x86_64-unknown-linux-gnu, compiled by gcc (GCC)
4.4.6 20110731 (Red Hat 4.4.6-3), 64-bit
(1 row)

The lock infomation, pid 17225 was granted
> # select * from pg_locks where transactionid = 45463704;

> locktype | database | relation | page | tuple | virtualxid |
transactionid | classid | objid | objsubid | virtualtransaction | pid | mode | granted | f
> astpath
>
---------------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+-------+---------------+---------+--
> --------
> transactionid | | | | | |
45463704 | | | | 131/103 | 17225 |
ExclusiveLock | t | f
> transactionid | | | | | |
45463704 | | | | 185/44 | 24592 |
ShareLock | f | f
> (2 rows)

The query is come from 192.168.232.43，but we already killed the process
at that server, there is no tcp connection from that server, the
following command output nothing.
> # netstat -anp | grep 192.168.232.43

Postgres process stat which running the query, it's doing a insert.
> postgres 17225 0.0 0.0 1763812 19056 ? Ss 21:48 0:00
postgres: searcher vacation 192.168.232.43(64757) INSERT
>

Strace info for pid 17225
> # strace -p 17225
> Process 17225 attached - interrupt to quit
> semop(877035566, {{5, -1, 0}}, 1

backtrace for pid 17225, we found there is running some function named
like spgxxxx
> Missing separate debuginfos, use: debuginfo-install
pg92-9.2.2-2.el6.x86_64
> (gdb) bt
> #0 0x0000003d6baea747 in semop () from /lib64/libc.so.6
> #1 0x00000000005fef57 in PGSemaphoreLock ()
> #2 0x000000000063f1a4 in LWLockAcquire ()
> #3 0x00000000004b7002 in spgdoinsert ()
> #4 0x00000000004b25e1 in spginsert ()
> #5 0x00000000007155a4 in FunctionCall6Coll ()
> #6 0x000000000047b4e0 in index_insert ()
> #7 0x00000000005871d2 in ExecInsertIndexTuples ()
> #8 0x0000000000594747 in ExecModifyTable ()
> #9 0x000000000057de18 in ExecProcNode ()
> #10 0x000000000057ccb1 in standard_ExecutorRun ()
> #11 0x000000000064e93f in ProcessQuery ()
> #12 0x000000000064eb6f in PortalRunMulti ()
> #13 0x000000000064f32e in PortalRun ()
> #14 0x000000000064cba2 in PostgresMain ()
> #15 0x000000000060a547 in ServerLoop ()
> #16 0x000000000060d077 in PostmasterMain ()
> #17 0x00000000005ac3d0 in main ()

We have lots data to insert in that table which have the spgist index,
may be the spgist index have a bug on a heavy write condition?

Thanks

Best Regards!