-
postgresql数据库的 死锁，逻辑推导过程
这是一次完全剥离所有修辞、抛弃一切应用层概念的纯物理级推演。 我们将直接下潜到 PostgreSQL 内核共享内存区，仅使用 C 语言的 PGPROC（进程状态）、LOCK（资源实体）、PROCLOCK（持有契约） 这三大核心结构体，以及底层的双向链表（Doubly Linked List）和操作系统信号量（Semaphore），把死锁的完整生命周期， ...
-
postgresql数据库 死锁 检查测机制
在关系型数据库的工程实现中，死锁检测（Deadlock Detection）是整个锁体系中最消耗计算资源的核心算法。死锁绝对不是应用层抛出的一个简单报错，而是一场发生在共享内存中，涉及硬件中断、有向图算法（DFS）、轻量级闩锁（LWLock）拦截与内存指针重排的物理级战役。 我们现在彻底剥离所有的概念包装，完全基于 Pos ...
-
死锁 软等待 ，慢动作拆解逻辑讲透
这是一次极其极致的底层 C 语言与图论算法的交叉推演。 在绝大多数 DBA 的认知里，只要发生死锁，数据库就一定会报错并杀掉一个事务。但在 PostgreSQL/openGauss 的底层源码中，死锁检测器（Deadlock Detector）的第一使命根本不是杀人，而是“救人”。 它救人的核心物理手段，就是针对**“软等待（Soft Wait / Sof ...
-
postgresql数据库 锁管理器 相关
PostgreSQL 数据库中，锁管理器（Lock Manager） 并不是一个独立的后台进程，而是一套存在于**共享内存（Shared Memory）**中的极其精密的数据结构和算法集合。所有的数据库读写进程（Backend Processes）在触碰底层数据之前，都必须“自觉”地按照同一套 C 语言算法，来到这片共享内存区域进行登记和冲突判定。 Pos ...
-
postgresql数据库 proclock结构体中 tag 字段 的作用推导：
一：tag 字段 的作用推导一： 在 PostgreSQL 的 C 语言源码中，PROCLOCK 结构体的第一行定义，就是一个名为 tag 的嵌套结构体（类型为 PROCLOCKTAG）。 分 4 步极其冷酷地把这个 tag 字段在底层内存寻址中的绝对统治力推导出来！ 第一步绝境：茫茫内存中的“寻人启事”（哈希表的寻址危机） 【物理绝境 ...
-
逻辑推导出 holdMask 字段 的作用
全局的 LOCK 结构体里有一个 grantMask，它记录了“当前这张表被所有人加上了哪些锁”。 既然全局已经有了状态指示灯，为什么在 PROCLOCK（人与物的契约）结构体内部，还要单独设计一个 holdMask（持有掩码） 字段？ 我们继续用**“假设没有它会发生什么灾难”**的底层逻辑推演法，分 4 步把它在 C 语言级别的绝对 ...
-
proclock结构体中 releaseMask 字段的作用，逻辑推演
在工业级数据库内核的真实 C 语言源码（src/backend/storage/lmgr/lock.c 与 README）中，releaseMask 的真正物理使命， 是为了在事务提交（COMMIT）的瞬间，利用“无锁化（Lock-Free）”的思想，解决 10000 把锁同时释放时引发的 LWLock（轻量级闩锁）雪崩争用灾难。 我们彻底抛弃表象，直接下潜到多核 CPU 的高速缓 ...
-
资源哈希表 和 关系哈希表 是同时生成的吗？？
要回答这个问题，我们必须在物理层面上，把“哈希表本身（容器）”和“哈希表里的结构体（数据）”彻底切分开来。 直接给出精确结论： 作为“容器”的两张全局哈希表，是 100% 同时生成的；但里面用来装数据的 LOCK 和 PROCLOCK 结构体，存在着极其严格的“先后物理因果顺序”，绝对不是同时生成的！ 我们按数据库的 ...
-
LockMethodProcLockHash（契约哈希表） 的结构包含哪些内容？
把目光死死锁定在了 LockMethodProcLockHash（契约哈希表）的内部结构上，直接进入了**“内核架构师在写 C 语言代码时，到底往这块内存里塞了什么，才让系统运转起来”**的终极物理拆解阶段。 在这张契约哈希表中，真正存储的 Value 对象，就是我们在前面反复提到的核心结构体 —— PROCLOCK。 在 PostgreSQL 的 C ...