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

表级锁命令LOCK TABLE

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

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

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

name：表名
lockmode：表级锁模式，即SHARE、EXCLUSIVE、ACCESS SHARE、ACCESS EXCLUSIVE、ROW SHARE、ROW EXCLUSIVE、SHARE UPDATE EXCLUSIVE、SHARE ROW EXCLUSIVE
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

transactionid代表事务id，简写为“xid”
virtualxid代表虚拟事务id，简写为“vxid”
每产生一个事务id，都会在pg_clog下的commit log文件中占用2bit
最早pg中本没有虚拟事务id，但是后来发现，有一些事务根本没有产生任何实质的变更，如一个只读事务或一个空事务，若在这种情况下也分配一个事务id会造成浪费，于是提出了虚拟事务id的概念
对于这类只读事务，值分配一个虚拟事务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设计成不在内存中记录行锁信息。

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

原文地址：https://blog.csdn.net/wozaibohaibian/article/details/131160786