表级锁命令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
pg_locks并不能显示出每个行锁的信息,因为行锁信息并不会被记录到共享内存中。如果记录到内存,意味着对表做全表更新时,表有多少行就需要在内存中记录多少条行锁信息,那么内存会吃不消,所以postgreSQL设计成不在内存中记录行锁信息。
思考:如何获取进程是在哪一行上被阻塞的?