ITPub博客

一次真实的 PostgreSQL OOM 事故某生产集群在占用 2TB 内存后，被 OOM killer 终止，而此时 work_mem 参数仅设置为 2MB。这一现象看似矛盾，却暴露了 PostgreSQL 内存管理中容易被忽视的核心问题——即便配备高性能硬件，峰值时段的单条查询仍可能导致整个集群宕机，而这类问题的解决，往往依赖于对数据库底层机制的深度理解，而非单纯的搜索引擎检索。需特别说明：下

🔔 关注【IvorySQL开源数据库社区】公众号即可获取 PostgreSQL 一手干货与最新动态⚙️ PostgreSQL技术文章🧩 代理困境：为什么我的 Postgres 控制平面需要保持确定性这篇文章反对在 PostgreSQL 核心控制平面操作中使用 AI 代理，比如扩容和故障转移。作者主张将这些关键任务保留在确定性的策略驱动自动化系统中，而不是交给概率性的 AI 系统。虽然 AI 代理正

🔔 关注【IvorySQL开源数据库社区】公众号即可获取 PostgreSQL 一手干货与最新动态📨 PostgreSQL Hacker 电子邮件讨论精选🧩 在进行采样之前，先在 postgres_fdw 中导入统计信息Etsuro Fujita 审查了 postgres_fdw 统计信息导入补丁并提供了多项修改意见。他撤回了此前关于 StatisticsAreImportable 回调函数的提案

🔔 关注【IvorySQL开源数据库社区】公众号即可获取 PostgreSQL 一手干货与最新动态📨 PostgreSQL Hacker 电子邮件讨论精选🧩 REPACK 的并发执行选项Alvaro Herrera 对 REPACK CONCURRENTLY 补丁系列提供了最新进展。他表示补丁 0001 状态良好，但在补丁 0003 准备好提交之前不会先提交它。他之前对补丁 0002 感到困惑，认

🔔 关注【IvorySQL开源数据库社区】公众号即可获取 PostgreSQL 一手干货与最新动态📨 PostgreSQL Hacker 电子邮件讨论精选🧩 pg_waldump：支持从 tar 文件中直接解析 WAL 日志pg_waldump tar 归档支持功能的测试在 Thomas Munro 的 FreeBSD 机器上持续失败。问题源于 FreeBSD tar 默认为 WAL 文件创建稀疏

🔔 关注【IvorySQL开源数据库社区】公众号即可获取 PostgreSQL 一手干货与最新动态⚙️ PostgreSQL技术文章🧩 零停机补丁（上）：预热机制Neon 介绍了他们的零停机补丁方案，重点讲述预热技术。该公司通过冗余设计和自动故障转移系统来确保数据库可用性。虽然在大规模系统中计划外故障在统计上是必然的，但 Neon 开发了在计划维护和补丁期间最小化停机时间的方法。这是探讨零停机补丁

🔔 关注【IvorySQL开源数据库社区】公众号即可获取 PostgreSQL 一手干货与最新动态⚙️ PostgreSQL技术文章🧩 Neon 与 Stripe Projects 集成实现自动配置Neon 已与 Stripe Projects 集成，让 AI 编程代理能够自动配置 PostgreSQL 数据库。此前，AI 代理虽然能够编写代码和创建迁移文件，但无法处理启动数据库或管理凭据等运维操

🔔 关注【IvorySQL开源数据库社区】公众号即可获取 PostgreSQL 一手干货与最新动态⚙️ PostgreSQL技术文章🧩 六边形网格、超级表与240个废弃标签：海事数据平台迁移至 TimescaleDBVesselAPI将其海事AIS追踪平台从MongoDB迁移到TimescaleDB，每小时处理70万条船舶位置报告。这次迁移解决了MongoDB在时序数据和空间查询方面的局限性。Ti

在 PostgreSQL 中，INSERT ... ON CONFLICT 是处理 Upsert（插入或更新） 的核心语法之一。自 PostgreSQL 9.5 引入该能力以来，开发者已经可以在插入冲突时选择 忽略记录（DO NOTHING） 或 更新记录（DO UPDATE）。在 PostgreSQL v19 中，这一语法进一步扩展：新增 ON CONFLICT ... DO SELECT。 当

设想如下数据库场景：两张表通过外键关联，外键字段为 NOT NULL，且约束有效并被严格执行。在执行两表 JOIN 查询时，却返回空结果。该场景看似不可能出现，但实际生产环境中出现了一个未被预期的边界情况。问题场景假设以车辆所有权管理场景为例，包含两张表，分别是车主表与车辆表：db=# CREATE TABLE owner (   &n

在数据库系统中，查询往往受限于 I/O 性能，因此优化工作通常聚焦于减少页面读取次数。索引是典型手段之一，但无法解决所有问题。Postgres 通过在表主存储（heap）及索引中维护多版本行数据，以支持并发查询的一致性。旧版本行在不再需要前仍占用空间，并可被后续复用。这部分额外空间通常称为“膨胀（bloat）”。本文将分析堆表膨胀与索引膨胀对查询性能的影响，以及对应的预防与处理方案。在 pgMus

在开发实践中，经常会遇到一个问题：如何在不修改 PostgreSQL 内核代码的前提下，为数据库对象附加自定义元数据。本文展示了一种基于 PostgreSQL SECURITY LABELS 机制的可行方案，用于实现自定义属性。这种方式具备事务性、与数据库对象强关联，并且能够与标准 PostgreSQL 操作良好协同。问题背景：复制冲突的管理在一个典型的两主节点向第三节点复制数据的架构中，UPDA

分区表是 PostgreSQL 的核心特性之一，但有一个问题即便资深用户也常会产生困惑：在涉及分区时，ALTER TABLE 语句的具体执行逻辑是怎样的？操作是否会同步至各分区？是否对新建分区生效？ONLY 关键字是否实现预期效果？为何部分命令可在主表执行却无法在分区执行，或反之？当前 PostgreSQL 官方文档对单个 ALTER TABLE 子命令的说明较为完善，但很少系统性地解释它们在分区

在使用 PostgreSQL 数据库的过程中，有一组实践方式可以显著提升开发与协作体验。单个做法影响有限，但叠加起来效果十分明显。使用 UUID 作为主键UUID 确实存在一些缺点：完全随机的 UUID 无法自然排序，对索引有一定影响相比自增 ID 占用更多存储空间（而存储通常是成本最低的资源）但 UUID 的优势远大于缺点：生成 UUID 无需与数据库协调可以安全地对外公开和传递CREATE&n

关于作者：Nickyoung，数据库领域从业者。PostgreSQL ACE，IvorySQL 专家顾问委员会成员。公众号“👉PostgreSQL 运维之道”。还在以最终 cost 来判断计划是否最优？那就大错特错了！！！本篇老杨和大家一起抽丝剥茧，从源码入手分析计划跑偏的原因。问题现象一个简单查询运行 240s，从执行计划看耗时主要在 nestloop join，Outter 扫描了 2293

PostgreSQL 18 正式发布，带来了多项重要改进，其中 RETURNING 子句的增强尤为突出。该特性在 MERGE RETURNING 场景下实现了关键突破，可显著简化应用架构，并提升数据变更追踪能力。RETURNING 子句的演进RETURNING 子句长期以来用于在 INSERT、UPDATE、DELETE 操作后返回受影响行的数据，从而避免额外的 SELECT

关于作者：Nickyoung，数据库领域从业者。PostgreSQL ACE，IvorySQL专家顾问委员会成员。公众号 “ 👉 PostgreSQL 运维之道 ”。给大家分享一个有趣的案例，同一个 sql，索引扫描比全表顺序扫描获取的数据更少。本篇我们深入分析一起索引排序规则损坏的案例，并 debug 验证索引扫描的主要过程。问题现象走索引扫描查询到 1 条数据。testid

PostgreSQL 在各行各业的关键应用中具有极高适用性。尽管 PostgreSQL 提供了良好的性能，但仍存在一些用户不太关注但对整体效率与速度至关重要的问题。多数人认为增加 CPU 核数、更快的存储、更大内存即可提升性能，但还有同样重要的因素需要关注——那就是延迟。延迟意味着什么？数据库执行查询操作的耗时，仅占应用程序接收查询结果总耗时的极小部分。下图可直观呈现该过程的内在逻辑：客户端应用发

在 PostgreSQL 中，SQL 查询的解析、执行等全流程的触发，均以应用程序与数据库建立有效连接为前提。这一连接建立过程看似是简单的交互握手，实则背后蕴含复杂的底层机制——涵盖进程管理、身份认证，以及保障高效通信的二进制协议等核心环节。深入理解 PostgreSQL 的连接处理机制，不仅能明晰连接池的重要性、掌握连接问题的排查思路，还可厘清其架构与基于线程的数据库的本质差异。下文将完整梳理应

作者简介：怀玉杰，瀚高股份研发工程师，负责 AI 方向研发，擅长算法分析与 AI 应用。医院数据管理的挑战介绍当前医院的信息系统呈现出多系统并存的复杂局面。一家三甲医院通常运行着数十个不同的业务系统：HIS（医院信息系统）处理核心业务，EMR（电子病历系统）记录诊疗过程等。并且医院场景本身复杂多变，患者从入院到出院整个过程往往要经历多个阶段：入院登记、床位分配、科室调整、检查与治疗、最终出院。以床