我正在使用 Python 和 psycopg2 运行大量查询。我创建了一个包含约 200 万行的大型临时表,然后使用以下命令一次从中获取 1000 行cur.fetchmany(1000)
并运行涉及这些行的更广泛的查询。不过,广泛的查询是自给自足的 - 一旦完成,当我继续进行下 1000 个查询时,我就不再需要它们的结果了。
然而,大约 1000000 行中,我从 psycopg2 得到了一个异常:
psycopg2.OperationalError: out of shared memory
HINT: You might need to increase max_locks_per_transaction.
有趣的是,当我执行查询以删除更广泛的查询创建的一些临时表时,就发生了这种情况。
为什么会发生这种情况?有什么办法可以避免吗?令人烦恼的是,这种情况发生在一半,这意味着我必须重新运行一遍。什么可能max_locks_per_transaction
有什么关系吗?
注意:我没有做任何事情.commit()
s,但我正在删除我创建的所有临时表,而且对于每个“广泛”事务,我只触及相同的 5 个表,所以我不明白表锁耗尽可能会成为问题。 。
当您创建一个表时,您将获得一个持续到事务结束的排他锁。即使你随后继续放弃它。
因此,如果我启动一个 tx 并创建一个临时表:
steve@steve@[local] *=# create temp table foo(foo_id int);
CREATE TABLE
steve@steve@[local] *=# select * from pg_locks where pid = pg_backend_pid();
locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid | mode | granted
---------------+----------+-----------+------+-------+------------+---------------+---------+-----------+----------+--------------------+-------+---------------------+---------
virtualxid | | | | | 2/105315 | | | | | 2/105315 | 19098 | ExclusiveLock | t
transactionid | | | | | | 291788 | | | | 2/105315 | 19098 | ExclusiveLock | t
relation | 17631 | 10985 | | | | | | | | 2/105315 | 19098 | AccessShareLock | t
relation | 17631 | 214780901 | | | | | | | | 2/105315 | 19098 | AccessExclusiveLock | t
object | 17631 | | | | | | 2615 | 124616403 | 0 | 2/105315 | 19098 | AccessExclusiveLock | t
object | 0 | | | | | | 1260 | 16384 | 0 | 2/105315 | 19098 | AccessShareLock | t
(6 rows)
当我删除表时,这些“关系”锁不会被删除:
steve@steve@[local] *=# drop table foo;
DROP TABLE
steve@steve@[local] *=# select * from pg_locks where pid = pg_backend_pid();
locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid | mode | granted
---------------+----------+-----------+------+-------+------------+---------------+---------+-----------+----------+--------------------+-------+---------------------+---------
virtualxid | | | | | 2/105315 | | | | | 2/105315 | 19098 | ExclusiveLock | t
object | 17631 | | | | | | 1247 | 214780902 | 0 | 2/105315 | 19098 | AccessExclusiveLock | t
transactionid | | | | | | 291788 | | | | 2/105315 | 19098 | ExclusiveLock | t
relation | 17631 | 10985 | | | | | | | | 2/105315 | 19098 | AccessShareLock | t
relation | 17631 | 214780901 | | | | | | | | 2/105315 | 19098 | AccessExclusiveLock | t
object | 17631 | | | | | | 2615 | 124616403 | 0 | 2/105315 | 19098 | AccessExclusiveLock | t
object | 17631 | | | | | | 1247 | 214780903 | 0 | 2/105315 | 19098 | AccessExclusiveLock | t
object | 0 | | | | | | 1260 | 16384 | 0 | 2/105315 | 19098 | AccessShareLock | t
(8 rows)
事实上,它又添加了两个锁...似乎如果我不断创建/删除该临时表,它每次都会添加 3 个锁。
所以我想一个答案是您将需要足够的锁来应对整个事务中添加/删除的所有这些表。或者,您可以尝试在查询之间重用临时表,只需截断它们即可删除所有临时数据?
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)