PostgreSQL如何查看事务所占有的锁？

表级锁命令LOCK TABLE

在PG中，显式地在表上加锁的命令为“LOCK TABLE”，此命令的语法如下：

LOCK [TABLE] [ONLY] name [,...][IN lockmode MODE] [NOWAIT]

语法中各项参数说明如下：

1. name：表名
2. lockmode：表级锁模式，即SHARE、EXCLUSIVE、ACCESS SHARE、ACCESS EXCLUSIVE、ROW SHARE、ROW EXCLUSIVE、SHARE UPDATE EXCLUSIVE、SHARE ROW EXCLUSIVE
3. NOWAIT：如果没有NOWAIT这个关键字，当无法获得锁时会一直等待，而如果加了NOWAIT关键字，在无法立即获取该锁时，此命令会立即退出并且报错

在PG中，事务自己的锁是从不冲突的，因此一个事务可以在持有SHARE模式的锁时再请求ROW EXCLUSIVE锁，而不会出现自己的锁阻塞自己的情况。

当事务要更新表中的数据时，应该申请ROW EXCLUSIVE锁，而不应该申请SHARE锁，因为在更新数据时，事务还是会对表加ROW EXCLUSIVE锁，想象一下，在两个并发的事务都请求SHARE锁后，开始更新数据前要对表加ROW EXCLUSIVE锁，但由于各自先前已加了SHARE锁，所以都要等待对方释放SHARE锁，因而出现死锁。从这个示例可以看出，如果涉及多种锁模式，那么事务应该总是最先请求最严格的锁模式，否则就容易出现死锁。

行级锁命令

显式的行级锁命令是由SELECT命令后加如下子句来构成的：

SELECT ... FOR {UPDATE | SHARE} [OF table_name [,...]] [NOWAIT] [...]

• NOWAIT关键字加上，如果无法获得锁则直接报错，而不会一直等待。
• OF table_name明确指定表名字，那么只有被指定的表会被锁定，其他在SELECT中使用的表则不会
• 不带OF table_name的FOR UPDATE或者FOR SHARE子句将锁定该命令中使用的所有表
• 如果FOR UPDATE或者FOR SHARE应用于一个视图或者子查询，那么它将同样锁定该视图或者子查询中使用到的所有表
• 主查询中引用了WITH查询时，WITH查询中的表并不会被锁定
• 如果想要锁定WITH查询内的表行，需要在WITH查询内指定FOR UPDATE或者FOR SHARE关键字

锁的查看

我们经常需要查看一个事务产生了哪些锁，哪个事务被哪个事务阻塞了，若执行一条SQL语句时阻塞住了，需要查询为什么阻塞，是谁阻塞住的，这些信息可以通过查询系统视图“pg_locks”来得到。pg_locks视图中各列的描述如下：

列名称	列类型	引用	描述
locktype	text		被锁定的对象类型：relation、extend、page、tuple、transactionid、virtualxid、object、userlock、advisory
database	oid	pg_database.oid	锁定对象的数据库OID，如果对象是一个共享对象，不属于任何数据库，此值为“0”，如果对象是“transaction ID”，此值为空
relation	oid	pg_class.oid	如果对象不是表或只是表的一部分，则此值为“NULL”，否则此值是表的OID
page	integer		表中的页号，如果对象不是表行（tuple）或表页（relation page），则此值为“NULL”
tuple	smallint		页内的行号（tuple）
virtualxid	text		虚拟事务id
transactionid	xid		事务id
classid	oid	pg_class.oid	包含该对象系统目录的id
objid	oid	any OID column	对象在系统目录的oid
objsubid	smallint		如果对象是表列（table column），此列的值为列号，这时classid和objid指向表
virtualtransaction	text		持有或等待这把锁的虚拟事务id
pid	integer		持有或等待这把锁的服务进程的PID，如果此锁是被一个两阶段提交的事务持有，则此值为NULL
mode	text		锁的模式名称，如“ACCESS SHARE”“SHARE”“EXCLUSIVE”等锁模式
granted	boolean		如果锁已被持有，此值为True，如果等待获得此锁，则此值为False

上述中，描述事务id的字段有三个：

• virtualxid
• transactionid
• virtualtransaction

1. transactionid代表事务id，简写为“xid”
2. virtualxid代表虚拟事务id，简写为“vxid”
3. 每产生一个事务id，都会在pg_clog下的commit log文件中占用2bit
4. 最早pg中本没有虚拟事务id，但是后来发现，有一些事务根本没有产生任何实质的变更，如一个只读事务或一个空事务，若在这种情况下也分配一个事务id会造成浪费，于是提出了虚拟事务id的概念
5. 对于这类只读事务，值分配一个虚拟事务id，而不是实际分配一个真实的事务id，这样就不需要在commit log中占用2bit的空间了

pg_locks这张视图的字段分为以下两部分：

• virtualtransaction之前的字段（不包括virtualtransaction字段），我们称其为“第一部分”，用于描述锁定对象（Locked Object）信息
• virtualtransaction之后的字段（包括virtualtransaction字段），我们称其为“第二部分”，用于描述持有锁或等待锁的session信息

了解上述概念后，可以容易理解virtualxid和virtualtransaction两个字段的意思：

• virtualxid在第一部分字段中，表示锁对象是一个virtualxid
• virtualtransaction表示持有锁或等待锁session的虚拟事务id

表锁实操

1.先开一个psql窗口，命令如下：

第一个窗口，查询PID，并锁定一张表。

2.第二个窗口中查看数据库中的锁的情况：

sql命令：

select locktype,relation::regclass as rel,virtualxid as vxid,transactionid as xid,virtualtransaction as vxid2,pid,mode,granted from pg_locks where pid = 12264;

通过上述图片可以看出：

• 第一行显示的是事务在自己的“virtualxid”上加的ExclusiveLock锁，这是必定会加上的
• 第二行才是我们实际在表上加的锁“AccessExclusiveLock”

3.新增一个窗口，显示地对表加锁：

执行sql语句发现，该窗口的锁表语句会被阻塞住

4.查看两个进程的锁情况：

• 发现两个进程都对表加了锁
• 进程12264中的granted字段为t，说明它获得了这把锁
• 进程21052中的granted字段为f，说明该进程没有获得这把锁，从而被阻塞

行锁实操

1.第一个窗口执行如下操作（在加表锁的基础上加行锁）：

2.第二个窗口中查看数据库中的锁的情况：

行锁不仅会在表上加意向锁，也会在相应的主键上加意向锁。其中“jxx_test_pkey”就是表的主键。

3.另一个窗口加行锁：

该窗口阻塞

4.第二个窗口中查看数据库中的锁的情况：

xid为739的锁被进程12264持有了，所以21052的进程获取锁标识为False

5.如何查看具体是哪一行数据被阻塞

-- 其中0和1分别代表pg_locks中的page和tuple字段
select * from jxx_test where ctid = '(0,1)'

pg_locks并不能显示出每个行锁的信息，因为行锁信息并不会被记录到共享内存中。如果记录到内存，意味着对表做全表更新时，表有多少行就需要在内存中记录多少条行锁信息，那么内存会吃不消，所以postgreSQL设计成不在内存中记录行锁信息。

---

思考：如何获取进程是在哪一行上被阻塞的？