postgresql中的咨询锁（advisory lock）

咨询锁（advisory lock），有的地方翻译为顾问锁，作为Postgresql中一种特有的锁，关于对其介绍，仅从咨询锁的描述性定义来看，一开始还真的没明白这个咨询锁是干什么的。

暂时抛开咨询锁的概念，先说数据库中传统的锁机制。
默认情况下的事务性锁，读/写会自动加锁，读/写完成后会自动解锁（加解锁机制在细节上复杂），这是一种隐式的锁机制，Postgresql也不例外。
对于加锁后的并发控制，也就是默认的写不阻塞读，是通过MVCC解决的，这种锁完全不需要认为干预。
相对于隐式锁机制和MVCC并发控制机制，咨询锁可以认为是一种显式锁，需要人为地控制，这类锁需要显式的申请和释放，在使用这类锁的时候，可以自行控制读写的排他性。

什么场景下使用显式锁？
比如想实现写阻塞读，或者读阻塞读的场景，因为默认的隐式锁加上MVCC机制，是做不到的。
实际业务类型需求的场景也很多：一个经典的问题，并发情况下，对唯一键的存性判断，然后决定存在则更新，不存在则插入这种逻辑，就需要咨询锁，默认的MVCC下是做不到的，当然也不是说咨询锁只能做这个事儿。
再举个例子：多线程编程中的线程共享变量，在读写共享变量时需要线程锁做控制（比如python的lock.acquire()），完成之后释放锁，咨询锁就有点这个味道（当然不完全相同），这些都是隐式锁无法完成的。

Table 9-73. Advisory Lock Functions

• 1，申请/释放：有申请就有释放，Session级别的锁需要显式释放，随着连接的关闭自动释放；事务级别的锁也需要显式释放，或者会随着事务的结束（提交或者回滚）一并释放

• 2，锁类型：共享锁和排它锁，比如pg_advisory_lock是排它锁，pg_advisory_lock_shared是共享锁

• 3，生效范围：Session级的或者事务级的，很好理解，比如pg_advisory_lock是添加Session级的排它锁，pg_advisory_xact_lock是申请事务级排它锁

• 4，参数个数，这个看概念是有点蒙的，有的锁函数是1个参数，有的是2个参数，一个参数的情况下，锁是库级别的，举个例子就很容易理解了
  

  SessionA
  dbtest=> select pg_advisory_lock(id),* from t_advisory1 where id = 1;
   pg_advisory_lock | id
  ------------------+----
              | 1
  (1 row)
   
  SessionB
  dbtest=>select pg_advisory_lock(id),* from t_advisory2 where id = 1;
  --当前Session一直被挂起，或者说阻塞，直到SessionA解锁。

  这里的两个Session是在两个不同的表上申请的相同的Id的锁，但是SessionB一样会被阻塞，这个就是解释了pg_advisory_lock在一个参数的时候，是一个库级别的锁。
  如果想要设置一个同一个表的同一个Id的锁，相信聪明的少侠一定知道该怎么办了，pg_advisory_lock这个函数重载的两个参数的方法，就是在另外一个维度定义锁定信息的。
  这里说的两个参数，可以从不同维度定义锁定目标，而不是单单为了表级别的锁定。
  

• 5，等待行为，对于锁的申请，其结果有两种可能性，1是申请到了，2是没有申请到，对于没有申请到的情况，有两中可选行为，要么一直等下去，要么不等了直接返回表面没申请到
  对于上面所说的，SessionB因为无法获取Id上的排它锁，导致挂起的行为，对应用程序表现的不太友好，也容易造成长时间持有连接造成数据库连接的暴增，如何破解？
  如果注意上述列表中锁函数的返回值，就会返现，有一部分返回值是void，一部分返回值是boolean，返回boolean的方法就是可以根据锁定目标时，根据返回值来判断是否成功锁定。
  对于范围值为boolean的函数，请求发起后都会立即返回，只不过是如果成功申请到了锁，返回T（true），如果没有成功申请到锁，返回F（False）
  这样的话，处理起来就比较灵活一点，而不是在申请不到锁的时候，Session处于一直挂起的状态，用流行专业的术语说就是Session一直hang起（一直不怎么敢用hang这个词，感觉都是大神才能用的）

--锁定某个表的某一行
db01=# select pg_try_advisory_lock(cast('t1'::regclass::oid as int),id),id from t1 where id = 1;
 pg_try_advisory_lock | id
----------------------+----
 t                    |  1
(1 row)

--解锁锁定某个表的某一行
db01=# select pg_advisory_unlock(cast('t1'::regclass::oid as int),id),id from t1 where id = 1;
 pg_advisory_unlock | id
--------------------+----
 t                  |  1
(1 row)

--直接基于变量的锁定
db01=# select pg_try_advisory_lock(100,1);
 pg_try_advisory_lock
----------------------
 t
(1 row)

--同一个Session内可以重复锁定
db01=# select pg_try_advisory_lock(100,1);
 pg_try_advisory_lock
----------------------
 t
(1 row)

--解锁，解锁成功返回t
db01=# select pg_advisory_unlock(100,1);
 pg_advisory_unlock
--------------------
 t
(1 row)

--解锁，解锁成功返回t，多次加锁后需要多次解锁,如果脑袋没问题的话，相信没人会在一个Session或者事务里连续对一个Id加锁，虽然postgre支持这么干
db01=# select pg_advisory_unlock(100,1);
 pg_advisory_unlock
--------------------
 t
(1 row)

--如果解锁的时候锁不存在，解锁失败
db01=# select pg_advisory_unlock(100,1);
WARNING:  you don''t own a lock of type ExclusiveLock
 pg_advisory_unlock
--------------------
 f
(1 row)


db01=#


--如果上一个Session的排它锁解锁之前，其他Session尝试加锁，直接返回失败
db01=# select pg_try_advisory_lock(100,1);
 pg_try_advisory_lock
----------------------
 f
(1 row)


--活动锁的查看
select locktype as lc,relation::regclass as relname,page||','||tuple as ctid,virtualxid ,transactionid as txid,virtualtransaction,pid,mode,granted from pg_locks ;