-
postgresql数据库 死锁 检查测机制
在关系型数据库的工程实现中，死锁检测（Deadlock Detection）是整个锁体系中最消耗计算资源的核心算法。死锁绝对不是应用层抛出的一个简单报错，而是一场发生在共享内存中，涉及硬件中断、有向图算法（DFS）、轻量级闩锁（LWLock）拦截与内存指针重排的物理级战役。 我们现在彻底剥离所有的概念包装，完全基于 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 ...
-
PGPROC_1 申请 LOCK_A 成功。内存中生成契约 PROCLOCK_1A（状态为 granted = true）。底层c语言结构体配合工作的流程：
这是一次极度纯粹的 C 语言内核级内存推演。 屏蔽掉操作系统调度、屏蔽掉业务 SQL，直接进入 PostgreSQL 的共享内存（Shared Memory）深处。假设此时 PGPROC_1（业务进程 1）因为某种原因（例如申请 8 级强锁，或 Fast Path 已满），必须去全局哈希表中申请 LOCK_A（某张表的物理锁），并且最终申请成功（无冲突） ...