Python psycopg2共享内存不足，提示增加每个事务的最大预锁数

在postgresql 9.1中插入大量数据时。使用Python脚本，我们在此查询中得到以下错误：

X: psycopg2.ProgrammingError in /home/hosting/apps/X X_psycopg.py:162 in : Execute 'execute' ( SELECT * FROM xml_fifo.fifo WHERE type_id IN (1,2) ORDER BY type_id, timestamp LIMIT 10 ): out of shared memory HINT: You might need to increase max_pred_locks_per_transaction 我们增加了这个数字，但仍然得到了一个共享内存中的max_pred_locks_per_transaction=192。每次我们再次启动脚本时，它都会运行一段时间，然后给出此错误消息。在Postgres 8.1上，我们没有这个问题

以下是postgresql日志文件的一部分：

2012-06-28 02:55:43 CEST HINT: Use the escape string syntax for backslashes, e.g., E'\\'. 2012-06-28 02:55:43 CEST WARNING: nonstandard use of \\ in a string literal at character 271 2012-06-28 02:55:43 CEST HINT: Use the escape string syntax for backslashes, e.g., E'\\'. 2012-06-28 02:55:43 CEST WARNING: nonstandard use of \\ in a string literal at character 271 2012-06-28 02:55:43 CEST HINT: Use the escape string syntax for backslashes, e.g., E'\\'. 2012-06-28 02:56:11 CEST WARNING: there is already a transaction in progress 2012-06-28 02:57:01 CEST WARNING: there is already a transaction in progress 2012-06-28 02:57:01 CEST ERROR: out of shared memory 2012-06-28 02:57:01 CEST HINT: You might need to increase max_pred_locks_per_transaction. 2012-06-28 02:57:01 CEST STATEMENT: SELECT * FROM xml_fifo.fifo WHERE type_id IN (1,2) ORDER BY type_id ASC, timestamp LIMIT 10 2012-06-28 02:57:01 CEST ERROR: out of shared memory 2012-06-28 02:57:01 CEST HINT: You might need to increase max_pred_locks_per_transaction. 2012-06-28 02:57:01 CEST STATEMENT: SELECT * FROM xml_fifo.fifo WHERE type_id IN (1,2) ORDER BY type_id ASC, timestamp LIMIT 10

---

问题是什么？

PostgreSQL在9.1版中为可序列化事务添加了新功能，以避免以前在该隔离级别可能出现的一些序列化异常。您看到的错误只有在使用这些新的可序列化事务时才可能出现。某些工作负载遇到了您在9.1中使用可序列化事务时描述的问题

一种解决方案是使用可重复读取事务隔离级别，而不是可序列化。这将为您提供与9.1之前的PostgreSQL版本中可序列化事务完全相同的行为。在决定这样做之前，您可能希望仔细阅读这些差异，以便了解是否值得重新配置您的环境，以避免在可序列化隔离级别出现问题：

如果增加每个事务的max_pred_locks_无法解决此问题，您可以尝试在不占用太多RAM的情况下显著提高，您可以尝试增加max_连接而不增加实际使用的连接

我与麻省理工学院的Dan R.K.Ports一起研究了9.1的可序列化快照隔离特性。这个问题的原因是，在这个初始版本中，将多个细粒度谓词锁组合成单个粗粒度锁的启发式方法非常简单。我相信它是可以改进的，但是你能给我的任何关于它遇到这个问题的情况的信息，对于设计一个更好的启发式方法来说都是很有价值的。如果您能告诉我您正在使用的CPU数量、活动数据库连接的数量，以及您遇到的工作负载，我将非常感激

---

感谢您提供的任何信息，我对此问题深表歉意。

我们使用以下硬件：-双haxacore，带超读功能，因此24个逻辑处理器-24GB内存-160GB raid 1 Intel SSD存储分区在一个卷中，用于postgresql-avg 100-500短周期db连接Hi Kgrittn，问题再次出现，我观察了负载，但这并不重要：2.9%的CPU负载1.2和578mb PostgresqlI也在问题中添加了一些postgresql日志文件，也许您可以看到问题所在。到目前为止，我为遇到此错误的人提供了详细信息。就性能而言，对他们来说，最好的选择是按照提示中的建议提高配置参数，和/或使用连接池来减少活动数据库事务的数量。试图在12核上同时运行500个查询永远不会是最有效的选择。我们正在解决这个问题。最大600个连接，3000个最大pred，16核，32GB RAM，24GB共享缓冲区。高查询负载。