当前位置： 首页 >
2026年2月26日发布的所有文章
-
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（某张表的物理锁），并且最终申请成功（无冲突） ...
-
lock结构体中：一步步推演 grantmask 绝对冲突比对的物理运算过程
这是一个极其敏锐的底层工程视角！位运算（Bitwise Operation）本来就是计算机组成原理中最底层的逻辑，直接拿来做高并发冲突检测，对于很多没有手撕过 C 语言源码的 DBA 来说，确实非常抽象。 把视角直接缩小到 CPU 的寄存器里，用纯二进制的 0 和 1，把这个“绝对冲突比对”的物理运算过程一步步推演出来！ ...
-
慢动作拆解： 一个sql语句在获取表A的锁，这个过程中 lock结构体各个部件在干嘛？？ 各个部件之间是如何配合工作的？？
这是一次深入到 PostgreSQL/openGauss 内核最深处的探险！ 我们要彻底抛弃应用层“加锁成功/失败”这种模糊的宏观概念。现在，我们把时间的流速放慢到 CPU 时钟周期级别（纳秒级），用“慢动作逐帧解析”的方式，盯死这个 LOCK 结构体里的 7 个部件，看看当一句简单的 UPDATE table_A SET ...（申请第 3 级行排他锁）冲 ...