百度360必应搜狗淘宝本站头条
当前位置:网站首页 > 优雅编程 > 正文

PostgreSQL死锁相关(postgresql修改用户密码)

sinye56 2024-10-18 12:43 2 浏览 0 评论

作者:阎书利


记得原来一老大哥说他运维ORACLE,发现死锁的时候,总想着缓一缓,再拖一拖,没准再查看的时候。死锁就已经自己释放掉,不需要处理了(运维的无奈)。而在PostgreSQL中,事务可以按照任意顺序加锁。且PostgreSQL也有着其死锁处理机制。


当进程请求加锁的时候,如果失败,会进入等待队列。如果在队列中已经存在一些进程要求本进程中已经持有的锁,那么为了尽量避免死锁,可以把本进程插入到它们的前面。当一个锁被释放时,将会试图唤醒等待队列里的进程。这个行为预防了死锁的产生。


但是这种方法不能完全避免死锁的产生,PostgreSQL提供如下图的死锁检验机制。



且PostgreSQL使用等待图(WFG)来检验死锁,WFG为一个有向图,顶点ABC表示申请加锁的进程,XY有向边表示依赖关系。



图中的虚线为soft edge,实线为hard edge


当进程A和进程B都在某个锁的等待队列,且进程A在进程B的后边,两个进程的加锁要求冲突,进程A在等待进程B,则存在从A到B的有向边,名为soft edge;如果进程A的加锁要求和进程B已经持有的锁冲突,这时候从A指向B的为hard edge。


系统出现死锁当且仅当WFG出现环,如果WFG中有soft edge环,则可以通过拓扑排序对队列进行重排,尝试消除死锁。从顶点开始,沿着WFG有向边走,如果能回到顶点,说明出现死锁。如果路径没有出现soft edge,则直接终止此事务。如果存在soft edge,则记录所有的soft edge,并尝试对这个集合进行调整。


通过拓扑排序找到可行的方案,则采用此方案,消除死锁,(不一定是最优的),否则死锁清除失败,终止该事务。


以下为pg12.1有向边的数据结构


/*
 * One edge in the waits-for graph.
 *
 * waiter and blocker may or may not be members of a lock group, but if either
 * is, it will be the leader rather than any other member of the lock group.
 * The group leaders act as representatives of the whole group even though
 * those particular processes need not be waiting at all.  There will be at
 * least one member of the waiter's lock group on the wait queue for the given
 * lock, maybe more.
 */
typedef struct
{
    PGPROC     *waiter;         /* the leader of the waiting lock group */
    PGPROC     *blocker;        /* the leader of the group it is waiting for */
    LOCK       *lock;           /* the lock being waited for */
    int         pred;           /* workspace for TopoSort */
    int         link;           /* workspace for TopoSort */
} EDGE;


PostgreSQL对进程的检验过程为:

  1. 递归试图检验和消除死锁。
  2. 测试当前队列状态是否会发生死锁,如果不满足约束性检查,则死锁。对soft edge调整,并检验是否合法。
  3. 判断是否出现环,如果存在且不能调整,则死锁。


相关参数:

1.Postgresql中,有一个死锁等待事件的参数,默认是1s,也就是是说Postgresql后台进程会以1s的频率来检测是否存在死锁。



锁等待超时


2.Postgresql中同样可以设置锁等待的超时时间,意味着当前事务在请求一个锁的时候,一旦等待时长超出指定的时间,当前语句被中止。该参数的默认值为0,意味着发生锁等待的时候永远不超时,一直等待下去。默认情况下,锁超时之后,当前Session的任何语句都会被回滚,即便是执行一个commit。



以下为标准锁的锁模式以及对应的操作



锁手动处理:


1.查询阻塞:


postgres=# SELECT w.query as waiting_query,
postgres-# w.pid as w_pid,
postgres-# w.usename as w_user,
postgres-# l.query as locking_query,
postgres-# l.pid as l_pid,
postgres-# l.usename as l_user,
postgres-# t.schemaname || '.' || t.relname as tablename
postgres-# from pg_stat_activity w join pg_locks l1 on w.pid = l1.pid
postgres-# and not l1.granted join pg_locks l2 on l1.relation = l2.relation
postgres-# and l2.granted join pg_stat_activity l on l2.pid = l.pid join pg_stat_user_tables t on l1.relation = t.relid;
   waiting_query    | w_pid |  w_user  |            locking_query             | l_pid |  l_user  |   tablename
--------------------+-------+----------+--------------------------------------+-------+----------+----------------
truncate tab_ysl ; |  5391 | postgres | update tab_ysl set id =9 where id=1; |  5524 | postgres | public.tab_ysl
(1 row)
//其中l_pid为阻塞者的pid,w_pid为被阻塞者的pid。


2.查询表持有的锁:


postgres=# select  oid  from  pg_class  where  relname= 'tab_ysl';
 oid
------
24580 
(1 row)
使pg_class.oid=pg_locks.relation,则表tab_ysl上持有的锁为,RowExclusiveLock和
AccessExclusiveLock ,对应了update和truncate的操作。
postgres=# select * from pg_locks where pid in ('5524','5391');
   locktype    | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid  |        mode         | granted | fastpath
---------------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+------+---------------------+---------+----------
relation      |    13593 |     2659 |      |       |            |               |         |       |          | 7/11               | 5524 | AccessShareLock     | t       | t
relation      |    13593 |     2658 |      |       |            |               |         |       |          | 7/11               | 5524 | AccessShareLock     | t       | t
relation      |    13593 |     1249 |      |       |            |               |         |       |          | 7/11               | 5524 | AccessShareLock     | t       | t
relation      |    13593 |     3455 |      |       |            |               |         |       |          | 7/11               | 5524 | AccessShareLock     | t       | t
relation      |    13593 |     2663 |      |       |            |               |         |       |          | 7/11               | 5524 | AccessShareLock     | t       | t
relation      |    13593 |     2662 |      |       |            |               |         |       |          | 7/11               | 5524 | AccessShareLock     | t       | t
relation      |    13593 |     2685 |      |       |            |               |         |       |          | 7/11               | 5524 | AccessShareLock     | t       | t
relation      |    13593 |     2684 |      |       |            |               |         |       |          | 7/11               | 5524 | AccessShareLock     | t       | t
relation      |    13593 |     2615 |      |       |            |               |         |       |          | 7/11               | 5524 | AccessShareLock     | t       | t
relation      |    13593 |     1259 |      |       |            |               |         |       |          | 7/11               | 5524 | AccessShareLock     | t       | t
virtualxid    |          |          |      |       | 7/11       |               |         |       |          | 7/11               | 5524 | ExclusiveLock       | t       | t
virtualxid    |          |          |      |       | 6/181      |               |         |       |          | 6/181              | 5391 | ExclusiveLock       | t       | t
transactionid |          |          |      |       |            |           512 |         |       |          | 7/11               | 5524 | ExclusiveLock       | t       | f
relation      |    13593 |    24580 |      |       |            |               |         |       |          | 7/11               | 5524 | RowExclusiveLock    | t       | f
transactionid |          |          |      |       |            |           513 |         |       |          | 6/181              | 5391 | ExclusiveLock       | t       | f
relation      |    13593 |    24580 |      |       |            |               |         |       |          | 6/181              | 5391 | AccessExclusiveLock | f       | f
(16 rows)


杀掉阻塞者的进程,释放锁:


select pg_cancel_backend('上面查询到的阻塞着的pid');


##注意##pg_cancel_backend(‘阻塞者的pid值’);只能杀死select语句,对其他语句不生效,杀了之后查询发现还存在,考虑使用pg_terminate_backend(‘进程ID’);

相关推荐

RHEL8和CentOS8怎么重启网络

本文主要讲解如何重启RHEL8或者CentOS8网络以及如何解决RHEL8和CentOS8系统的网络管理服务报错,当我们安装好RHEL8或者CentOS8,重启启动网络时,会出现以下报错:...

Linux 内、外网双网卡路由配置

1.路由信息的影响Linux系统中如果有多张网卡的情况下,如果路由信息配置不正确,...

Linux——centos7修改网卡名

修改网卡名这个操作可能平时用不太上,可作为了解。修改网卡默认名从ens33改成eth01.首先修改网卡配置文件名(建议将原配置文件进行备份)...

CentOS7下修改网卡名称为ethX的操作方法

?Linux操作系统的网卡设备的传统命名方式是eth0、eth1、eth2等,而CentOS7提供了不同的命名规则,默认是基于固件、拓扑、位置信息来分配。这样做的优点是命名全自动的、可预知的...

Linux 网卡名称enss33修改为eth0

一、CentOS修改/etc/sysconfig/grub文件(修改前先备份)为GRUB_CMDLINE_LINUX变量增加2个参数(net.ifnames=0biosdevname=0),修改完成...

CentOS下双网卡绑定,实现带宽飞速

方式一1.新建/etc/sysconfig/network-scripts/ifcfg-bond0文件DEVICE=bond0IPADDR=191.3.60.1NETMASK=255.255.2...

linux 双网卡双网段设置路由转发

背景网络情况linux双网卡:网卡A(ens3)和网卡B(...

Linux-VMware设置网卡保持激活

Linux系统只有在激活网卡的状态下才能去连接网络,进行网络通讯。修改配置文件(永久激活网卡)...

VMware虚拟机三种网络模式

01.VMware虚拟机三种网络模式由于linux目前很热门,越来越多的人在学习linux,但是买一台服务放家里来学习,实在是很浪费。那么如何解决这个问题?虚拟机软件是很好的选择,常用的虚拟机软件有v...

Rocky Linux 9/CentOS Stream 9修改网卡配置/自动修改主机名(实操)

推荐...

2023年最新版 linux克隆虚拟机 解决网卡uuid重复问题

问题描述1、克隆了虚拟机,两台虚拟机里面的ip以及网卡的uuid都是一样的2、ip好改,但是uuid如何改呢?解决问题1、每台主机应该保证网卡的UUID是唯一的,避免后面网络通信有问题...

Linux网卡的Vlan配置,你可能不了解的玩法

如果服务器上连的交换机端口已经预先设置了TRUNK,并允许特定的VLAN可以通过,那么服务器的网卡在配置时就必须指定所属的VLAN,否则就不通了,这种情形在虚拟化部署时较常见。例如在一个办公环境中,办...

Centos7 网卡绑定

1、切换到指定目录#备份网卡数据cd/etc/sysconfig/network-scriptscpifcfg-enp5s0f0ifcfg-enp5s0f0.bak...

Linux搭建nginx+keepalived 高可用(主备+双主模式)

一:keepalived简介反向代理及负载均衡参考:...

Linux下Route 路由指令使用详解

linuxroute命令用于显示和操作IP路由表。要实现两个不同子网之间的通信,需要一台连接两个网络的路由器,或者同时位于两个网络的网关来实现。在Linux系统中,设置路由通常是为了解决以下问题:该...

取消回复欢迎 发表评论: