PostgreSQL中APP在涉及locks时需要注意的地方有哪些

这篇文章主要讲解了“PostgreSQL中APP在涉及locks时需要注意的地方有哪些”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“PostgreSQL中APP在涉及locks时需要注意的地方有哪些”吧！测试数据:— session 1— session 21: Never add a column with a default value
表上新增列时获取的锁是AccessExclusiveLock,会阻塞RW(包括SELECT),为了尽快完成列的添加,新增有默认值的列,可拆分为新增列,然后执行UPDATE语句以免出现R阻塞.使用先添加列,后更新默认值的方法虽然更新耗费的时间远比直接add column设置默认值要大,但锁等级是RowExclusiveLock,并不会阻塞读2: Beware of lock queues, use lock timeouts
PG中每一个锁都有一个队列,在获取锁时如需等待存在冲突的其他锁,则会阻塞.可通过设置超时时间避免长时间的等待.这样虽然会失败,但可通过后台查询等方法获取数据库活动,保持数据库可控.3: Cr免费主机域名eate indexes CONCURRENTLY
使用CONCURRENTLY模式创建Index.
新插入1000w数据普通模式创建索引回滚事务后,使用CONCURRENTLY模式创建索引,要注意的是CONCURRENTLY模式不能用在事务中不启动事务,直接执行使用CONCURRENTLY模式创建索引,获取的lock是ShareUpdateExclusiveLock,不会阻塞INSERT/UPDATE/DELETE操作(请求的锁是RowExclusiveLock)4: Take aggressive locks as late as possible
这个跟编程中定义变量类似 : 离需要用到的地方越近的地方才定义.文中的例子见仁见智,选择使用.5: Adding a primary key with minimal locking
重新构建测试数据把add pri免费主机域名mary key这一个动作拆解为先添加唯一索引,再添加primary key constraint这两个动作.拆解后,使用CONCURRENTLY模式创建索引,与第3点类似6: Never VACUUM FULLvacuum full请求的锁是AccessExclusiveLock,会阻塞读写,在目前vacuum full并不智能的情况下,手工发起对单个表的vacuum full会保险许多.7: Avoid deadlocks by ordering commands
注意命令的顺序,避免死锁产生死锁感谢各位的阅读，以上就是“PostgreSQL中APP在涉及locks时需要注意的地方有哪些”的内容了，经过本文的学习后，相信大家对PostgreSQL中APP在涉及locks时需要注意的地方有哪些这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是云技术，小编将为大家推送更多相关知识点的文章，欢迎关注！

相关推荐: 如何处理MySQL存储过程的权限问题

这篇文章主要介绍如何处理MySQL存储过程的权限问题，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！ MySQL的存储过程，没错，看起来好生僻的使用场景。问题源于一个开发同学提交了权限申请的工单，需要开通一些权限。 本来是一个很正常的操作…