Postgres ShareRowExclusiveLock 锁
我有一个加载 Postgres 服务器，有大量更新操作。在 Postgres.conf 中，我设置了 deadlock_timeout=8s。
在日志中我看到以下内容：
process 3588 acquired ShareRowExclusiveLock on relation 17360 of database 16392 after
8000.000 ms
这看起来真的很慢。您对此有何看法？ deadlock_timeout 是否有更好的值？还有哪些其他设置可以帮助缩短锁定时间？日志中的这一行表明事务已损坏且任何数据未更新？
I have a loading Postgres server with a large number of update operations. In Postgres.conf I set the deadlock_timeout=8s.
In the log I see the following:
process 3588 acquired ShareRowExclusiveLock on relation 17360 of database 16392 after
8000.000 ms
This seems really slow. What is your opinion on this? Is there a better value for deadlock_timeout? What other settings can help bring down lock times? And this line from the log says that the transaction was broken and any data was not updated?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当您显式发出 LOCK TABLE 语句时，将获取 ShareRowExclusiveLock。
LOCK TABLE的默认行为是请求对表的独占访问：在锁被释放之前没有人能够读取该表。PostgreSQL 使用多版本并发控制来处理数据库内的事务完整性。除非您遇到应用程序问题，否则我建议您关闭对 LOCK TABLE 的显式使用，或者尝试在几小时后运行批量更新操作。
如果您确实需要，我还建议您查看 显式锁 文档采取显式锁定。
ShareRowExclusiveLocks are acquired when you've explicitly issued a
LOCK TABLEstatement. The default behavior forLOCK TABLEis to request exclusive access to the table: nobody will be able to read from it until the lock is released.PostgreSQL uses multi-version concurrency control to handle transactional integrity within the database. Unless you're seeing application problems, I suggest turning off your explicit use of
LOCK TABLEor else trying to run your bulk update operation after hours.I'd also suggest looking into the Explicit Locks documentation if you do need to take explicit locks.
你读过这篇文章吗？
http://www.postgresql.org/docs/current/static /runtime-config-locks.html
Have you read this?
http://www.postgresql.org/docs/current/static/runtime-config-locks.html