- 博客(363)
- 收藏
- 关注
RSS订阅原创 案例-20260101分区数据更新失败
问题因 PG11 需子表发布分区表，新分区自动创建无主键致发布后无法更新；临时补主键，长期升 PG通过父表发布 + 继承主键。
2026-01-04 19:01:11
975
原创 论文精读|插件无政府状态
本文综述了数据库管理系统（尤其 PostgreSQL）的插件扩展机制。研究表明，PostgreSQL 插件生态最丰富，但兼容性问题突出：对 400 余个插件的测试显示，16.8% 的插件组合存在冲突，含 pg_hint_plan、Citus 等知名插件。插件实现以函数调用（92.5%）和钩子机制为主，安全与灵活性存权衡。此外，16.6% 的插件包含从 PG 源码复制的代码。研究揭示了数据库插件生态的 “无政府状态”，建议谨慎管理插件安装、推行版本收敛策略，为数据库扩展机制的设计与使用提供了重要参考。
2026-01-03 16:12:01
744
原创 论文精读|DBAIOps
传统数据库运维存在人力成本高、扩展性差、重复故障等问题。DBAIOps 创新融合 LLM 推理与知识图谱技术，通过 Neo4j 构建 ExperienceGraph 编码 DBA 经验，经两阶段图演化扩展异常关联，LLM 生成精准诊断报告。实验证明其显著优于传统方案，中型 LLM 即可奏效，支持知识增量更新，扩展性强，为运维自动化提供新思路。
2025-12-15 21:50:39
896
原创 从collation mismatch异常到其原理
PostgreSQL collation版本不匹配问题分析 问题现象： PostgreSQL 15数据库迁移后出现警告，提示"zh_CN.utf8" collation版本不匹配（数据库使用2.17版本，操作系统提供2.28版本）。 分析过程： 已排除数据库、字段和索引层面的collation问题 发现业务SQL中显式指定了"zh_CN.utf8" collation 检查确认pg_collation表中记录的版本(2.17)与操作系统实际版本(2.28)不一致 源码
2025-12-13 10:14:02
568
原创 案例-行锁与LWlock:lockmanger
1.行锁是因是果，是行锁的问题还是数据库性能下降SQL跑的慢了出现行锁？行锁是因。sql执行次数没有变化，但是sql的传参从离散变成集中，即更新同一行的情况明显增加。从压测数据来看更新同一行会出现行锁和LWLock LockManager的等待。2.sql执行次数没有上涨，SQL性能是否下降？SQL性能其实是下降了，但是索引肯定没有走错，只是因为反复更新了同一行。解决方案：从业务层了解SQL是某接口开关调用后讲调用次数更新到表里。如果是同一接口反复调用，是可能出现反复更新同一行的情况的。
2025-11-30 19:18:38
788
原创 论文精读|PolarDB-CXL|2025 SIGMOD最佳工业论文
聚焦 CXL 在云原生数据库分离内存的应用：CXL 作为高速互连标准，以低延迟、内存融合优化内存性能，对比 RDMA，在简化设计、减读写放大、提恢复效率上更优。论文提出 PolarCXLMem 系统（基于 CXL 2.0 交换机管分离内存），借 PolarRecv 用 CXL 内存持久性加速崩溃恢复。实验显示其延迟近本地 DRAM 且优于 RDMA，适配高带宽数据库，为云数据库内存架构拓新径。
2025-11-30 19:04:48
613
原创 论文精读|PolarDB-MP|2024 SIGMOD最佳工业论文
PolarDB-MP提出了一种新型多主云原生数据库架构，通过分离式共享内存和共享存储解决现有架构的扩展性问题。传统主从架构受限于主库吞吐，shared-nothing架构面临分布式事务开销，而现有共享存储多主方案存在冲突解决效率低的问题。PolarDB-MP的创新点包括：1) 所有节点平等访问数据，避免分布式事务；2) 基于RDMA的低延迟通信；3) 局部逻辑序列号(LLSN)确保一致性；4) 多主融合服务器(PMFS)实现事务/缓冲/锁融合。实验表明其在50%共享数据场景下，8节点可达7.8倍单节点吞吐。
2025-11-09 22:53:09
637
原创 案例-从distinct不准确到DISTINCT的计算原理
PostgreSQL统计信息中n_distinct值不准确的问题分析：大表默认采样3万行数据可能导致distinct值预估偏低。采样算法基于Haas-Stokes公式，其预估结果与采样中distinct值数量和单次出现值数量直接相关。测试显示，提高采样数量可改善准确性但增加分析时间。解决方案包括临时调整default_statistics_target参数或永久设置列级STATISTICS值（最大10000）。注意列的收集阈值优先级高于全局参数，且表阈值为各列最大阈值。
2025-10-19 10:38:16
449
原创 从静态表查询冲突到其原理
静态表查询冲突分析 摘要：在PostgreSQL主从架构中，静态历史表（无更新）的从库查询仍会遭遇"canceling statement due to conflict with recovery"错误。分析发现这是由于WAL日志中的HEAP2_CLEAN记录（对应页修剪操作）触发冲突所致。关键发现： 即使没有显式VACUUM操作，后台页修剪(PRUNE)也会生成WAL记录 这些记录包含remxid信息，会与从库查询的快照产生冲突 冲突发生在ResolveRecoveryConflic
2025-09-13 09:39:33
962
原创 案例-添加索引性能下降和generic plan
执行计划变化导致性能问题 问题现象：添加created_date索引后，SQL执行时间从3秒骤增至30多秒，导致CPU飙升。 执行计划对比： 加索引前：使用Nested Loop连接，通过task_no索引扫描各分区表，再过滤created_date条件 加索引后：改用Hash Join，直接利用created_date索引扫描所有分区表，导致扫描数据量剧增（rows=114435） 根本原因：优化器选择的新执行计划虽然利用了新增索引，但扫描数据量过大，反而导致性能下降。建议考虑调整查询条件或创建复合索引来
2025-09-13 09:35:15
975
原创 控制文件上的参数和主从参数不一致问题
8个参数在主库被修改并重启后，均会更新本地控制文件，如果参数有变会将改变后的参数写入wal中同步给下游，下游redo这个parameter change wal record，即更新本地的控制文件，从库根据一定条件来判断主从或者其他功能是否可用。
2025-07-29 10:05:09
1098
原创 案例-授权和walsender跑不动
PostgreSQL WALSender阻塞问题分析摘要 现象显示WALSender进程LSN未推进，CPU使用率高，堆栈显示阻塞在pathman插件的invalidate_psin_entries_using_relid函数。通过分析发现： WALSender在处理一个大型事务（XID=4285897514），该事务修改了约1.8万条pg_class记录 事务最后生成了大量无效消息（7万catcache和3万relcache） 这些修改主要涉及18523个系统表对象，占pg_class总记录的13% 问题
2025-06-21 10:39:56
917
原创 Linux内存进阶
进一步理解Linux内存，vm、cgroup如何运作和调配，如何监控内存pages的行为，postgresql在运维过程中会遇到什么OS内存问题···
2025-06-19 23:34:21
1118
原创 我的年终总结2024
我似乎每年都在说work-learning balance···由于今年工作量剧增，有段时间甚至都没办法学习了，balance已经被击碎。其实只要周围没人，学习效率就是高的。收集了一下今年我比较认可的话：不要让别人成为那你任务链上的依赖 --heisenberg.liu需要执行力的方案一般都是简单的方案 --heisenberg.liu没有落地的事情等于没有做 --somebody自己去想办法解决问题，而不是等别人回消息 --somebody。
2025-01-11 17:24:16
1700
原创 pg数据库运维经验2024
这篇文章主要是讲pg运维常见问题，两三年见一次的疑难杂症就不说了。主要是技术性运维总结，主打通俗易懂和快速上手，尽量避免源码层面等深入分析。
2025-01-08 21:14:28
1753
原创 PG停库逻辑和walsender阻止停库问题分析
有几种方法可以关闭pg库。在底层，它们都归结为向postmaster进程发送一个信号。signalpg_ctl含义SIGTERM不允许新的连接，但允许现有会话正常结束其工作。只有在所有会话终止后，它才会关闭SIGINT服务器不允许新的连接，并向所有现有的子进程发送SIGTERM，中止当前的事务并迅速退出。等待几乎所有子进程（有几个子进程不需要）退出，最后关闭SIGQUIT将向所有子进程发送SIGQUIT，并等待它们终止。如果在5秒内有子进程没有终止，它们将被发送SIGKILL注意，pg_ctl没有发送。
2025-01-04 13:11:45
1082
原创 读书笔记——DDIA-v2 设计数据密集型应用（第二版）
ddia-v2看完感觉爱不释手，只要是数据相关的知识都娓娓道来，为什么会这样？现在是怎样的？这样有什么问题？其中的看法和想法实在精辟、干练，甚至连每个章节的航海图都很有意思。
2024-09-19 23:14:09
2759
原创 Postgresql CLOG文件及其从库同步解析
放眼所有关系型数据库，PostgreSQL的clog也是很特殊的日志。CLOG的存在跟PG的MVCC机制不无关系
2024-09-03 20:38:47
1571
原创 PostgreSQL案例：planning time超长问题分析
库总是OOM，分析到是执行计划生成有问题，planning time 1秒，planning shared hit 100w。一通分析，定位到是统计信息基表pg_statistic膨胀，由于会话首次SQL执行时的CatCacheMiss，导致backend访问并缓存了pg_statistic过多的死元组数据。应用连接总会启用新会话，多个backend的总内存过大从而导致OOM。
2024-08-21 08:41:34
1699
1原创 案例：逻辑复制把checkpoint、walsender、backup全部卡死
pg数据库复制槽卡死、checkpoint卡死、备份卡死问题分析
2024-04-10 01:04:54
1431
事务的历史与SSI-PostgreSQL数据库技术峰会成都站分享
2023-06-21
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人