www.876873.xyz

💽 内部面孔：存储引擎层（高强度“纯写”状态）

• 主导进程：Startup 进程（数据库启动时拉起的第一个子进程）。
• 物理行为：它在后台以极高的 CPU 和 I/O 资源占用率，疯狂读取归档或流复制传来的 WAL 日志，并将这些日志中的 INSERT/UPDATE/DELETE 物理变更，逐字节地写入内存（Shared Buffers）中的 8KB 数据页，并不断触发磁盘的落盘（Flush）。
• 定性：在底层存储级别，数据库此刻绝对不是静止的，而是一台全速运转的物理写入机器。

🔌 外部面孔：网络接入层（取决于参数配置）

虽然底层在狂写，但对于前端通过 5432 端口发起的 TCP 连接，postmaster 会进行严格的拦截。外部表现完全取决于你在 postgresql.conf 中的 hot_standby 参数：

状态 A：绝对物理隔离（hot_standby = off，默认状态）

• 网络行为：postmaster 监听了端口，但拒绝分配工作进程。
• 物理反馈：任何客户端尝试连接，都会在握手阶段被直接踢断，并收到冰冷的 C 语言异常报错：FATAL: the database system is starting up。
• 定性：全盘拒绝连接（Startup Lockdown）。此时数据库对外部业务来说，就是一个连不上的黑洞。

状态 B：热备并发读取（hot_standby = on）

• 网络行为：postmaster 允许客户端建立连接，并正常分配后端的 backend 进程。
• 物理反馈：内核会在这些连接进程的内存上下文中，强行将会话标志位打上 XactReadOnly = true 的烙印。你可以执行 SELECT 读取数据，但只要你敢发出一句 UPDATE 或 INSERT，内核直接报错拒绝。
• 物理奇迹（MVCC 的发力）：此时，前台业务在读取 8KB 数据页，后台 Startup 进程同时在修改这同一个 8KB 数据页。内核依靠 MVCC 机制保证了读写绝对不冲突。
• 定性：并发受限读（Read-Only Hot Standby）。

---

💡 终极物理定言

总结一句话：在 recovery.signal 被删除之前，数据库就是一台**“内部在疯狂重做历史写入，外部要么完全连不上、要么只能受限执行 SELECT”**的时光机。

直到目标时间到达，内核完成强制 Checkpoint，调用 unlink() 物理删除这个信号文件，全局状态变量才会从 PM_RECOVERY 翻转为 PM_RUN（正常运行态），全面解除写保护，成为一个真正正常的读写主库。