PostgreSQL数据库中异常高的独占锁数量

Question

总的来说，我对数据库设计和PostgreSQL非常陌生，但我知道Postgres中行版本控制、事务和独占锁背后的一般概念(例如，这文章给出了相当好的概述)。

我目前的问题是，a) --我不知道为什么PG数据库日志文件中会出现这么多独占锁，而b) --为什么会出现这些锁。

我运行PostgreSQL 10 (+ PostGIS扩展)，在5个表(200 10)上有大约3亿行。我有大约5个脚本(4xPHP和1xPythonAPI)，运行24/7，可以进行大量的插入(如果条目已经存在，则使用DO UPDATE和COALESCE )。但是，据我所知，Postgres扩展在每次SQL查询之后自动提交，在我的Python脚本中，增加提交并不会显著减少锁。我有几个动态更新行的触发器，但据我所知，从日志文件中可以看出，它们不是锁的原因。通常情况下，我的两个或更多脚本同时插入/更新同一行是非常罕见的。

这是一个示例日志条目：

2018-01-31 01:04:02 CET [808]: [258-1] user=user1,db=maindb,app=[unknown],client=::1 LOG:  process 808 still waiting for ExclusiveLock on page 0 of relation 26889 of database 16387 after 1015.576 ms
2018-01-31 01:04:02 CET [808]: [259-1] user=user1,db=maindb,app=[unknown],client=::1 DETAIL:  Process holding the lock: 680. Wait queue: 1728, 152, 808.
2018-01-31 01:04:02 CET [808]: [260-1] user=user1,db=maindb,app=[unknown],client=::1 STATEMENT:  

                INSERT INTO "table1" (...) 
                VALUES (...)                                                                                                                                                                                              
                ON CONFLICT (...)                                                                                                                                                                                                                                                       
                DO UPDATE SET                                                                                                                                                                                                       
                ...;

我每2-3分钟就有类似的日志记录。它们有问题吗？它们到底意味着什么，锁是最终解决了，还是事务的数据丢失了？没有日志条目声明锁被解析或更新最终提交到数据库。

第二种类型的频繁日志条目类似于以下内容：

2018-01-31 07:22:16 CET [2504]: [16384-1] user=,db=,app=,client= LOG:  checkpoint complete: wrote 9999 buffers (3.8%); 0 WAL file(s) added, 0 removed, 7 recycled; write=269.842 s, sync=0.218 s, total=270.123 s; sync files=85, longest=0.054 s, average=0.002 s; distance=66521 kB, estimate=203482 kB
2018-01-31 07:22:46 CET [2504]: [16385-1] user=,db=,app=,client= LOG:  checkpoint starting: time  

这是否意味着自动登录或自动提交解决所有锁？

我的一般问题是:我是应该关心和做一些事情，还是干脆把事情留在原样上？

Answer 1

过了一会儿，我发现了是什么导致了这些锁，以及如何解决它们。所有排他锁都发生在数据库中的一个关系上：...ExclusiveLock on page 0 of relation 26889 of database...

26889是什么？

SELECT relname FROM pg_class WHERE OID=26889

结果：idx_post_hashtags

这一切都是由具有Array (Text)的特定列上的GIN索引引起的。此外，这个GIN索引是无用的，因为数组有一个可变的长度，并且查找任何特定的数组值都没有从索引中受益。我掉了:所有的独家锁具都没了！

仔细阅读日志确实有帮助。