pg的锁有两类，表级锁和行级锁。
|
ACCESS SHARE |
只读表不修改表申请该锁模式 |
|
|
ROW SHARE |
select for update 和select for share 申请该锁模式 |
|
|
ROW EXCLUSIVE |
DML申请该锁模式 |
|
|
SHARE UPDATE EXCLUSIVE |
VACUUM、ANALYZE、CREATE INDEX CONCURRENTLY申请该锁模式 |
|
|
SHARE |
create index 申请该锁模式 |
|
|
SHARE ROW EXCLUSIVE |
不会主动申请 |
|
|
EXCLUSIVE |
不会主动申请 |
|
|
ACCESS EXCLUSIVE |
alter table ，drop table，truncate，reindex ，vacuum full 申请该模式的锁 |
|
表级锁只有share和EXCLUSIVE两种，也就是读和写锁，share读锁加上后不能修改表，加锁exclusive写锁后不能读也不能写，但是在多版本功能后，修改某一行数据，实际上并没有改变原来那一行，而是另复制了一行数据，修改在新行上进行，事务不提交，别人是看不到修改行的，就没有必要阻塞其他用户读数据了。
在多版本功能下，ACCESS share 表明加上这个锁，即使是正在修改数据的情况下，也允许读数据，另一个锁ACCESS EXCLUSIVE 即使多版本功能，也不允许访问数据。
表级锁的锁粒度太大，出现了行级锁，mysql获得行锁之前需要获取意向锁，pg中类似mysql也有ROW_SHARE 和ROW_EXCLUSIVE锁。
意向锁之间不会冲突，意向锁和非意向锁的冲突兼容关系和普通锁之间关系一样。可以简单转换为X和S，在比较是否兼容。
就是把IX锁之间的不兼容变为更严格的一种锁，针对不带FULL的VACUUM，CREATE INDEX CONCURRENTLY都会申请该锁。
等同于加了S锁和IX锁
PG中共8种锁，共享锁SHARE 和排它锁EXCLUSIVE ，因为多版本的原因修改数据的同事允许读数据，于是有了ACCESS SHARE和ACCESS EXCLUSIVE锁。
为了处理表锁和行锁之间的关系，欧了意向锁的概念，ROW_SHARE 和ROW_EXCLUSIVE锁，但是意向锁之间不会冲突，为了更严格，出现了SHARE
UPDATE EXCLUSIVE和 SHARE ROW EXCLUSIVE锁。
