PG-X

pg_squeeze 是 CYBERTEC 开源的一个 PostgreSQL 扩展，提供了一个后台工作进程（每个数据库一个），定期监控用户定义的表，当检测到某个表超出了膨胀阈值时，pg_squeeze 会自动开始重建该表。重建过程在后台并发进行，它利用 PostgreSQL 内置的复制槽和 logical decoding，从 WAL 中提取重建期间发生的表更改。pg_squeeze 要求重建的表必须定义主键或唯一约束。 使用 pg_squeeze 需要在 postgresql.conf 中作相应的配置: wal_level = logical # pg_squeeze 使用 logical decoding shared_preload_libraries = 'pg_squeeze' # 用到了共享内存和 BackgroundWorker 用户可以通过将表的信息插入 squeeze.tables 表中来注册表。注册后，系统会定期检查表的状态，当满足条件时，会自动触发重建过程。对于不想注册表或者不需要预先检查膨胀的情况，可以手动重建。 -- 1. Register table for regular processing INSERT INTO squeeze.tables ( tabschema, tabname, schedule, free_space_extra, vacuum_max_age, max_retry ) VALUES ( 'public', 'bar', ('{30}', '{22}', NULL, NULL, '{3, 5}'), 30, '2 hours', 2 ); -- 2....

问题: PostgreSQL 中 UPDATE 操作 set 带索引的列，但值没变化还会走 HOT UPDATE 吗？ 我们用 PostgreSQL 14 internals 中的例子验证一下: CREATE TABLE accounts( id integer PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY, client text, amount numeric ); INSERT INTO accounts VALUES (1, 'alice', 1000.00), (2, 'bob', 100.00), (3, 'bob', 900.00); 用 PostgreSQL 14 internals 中提供的两个 UDF（见附录）heap_page 和 index_page 查看 heap 表和 btree 的页面 layout: # SELECT * FROM heap_page('accounts', 0); ┌───────┬────────┬──────┬──────┬─────┬─────┬────────┐ │ ctid │ state │ xmin │ xmax │ hhu │ hot │ t_ctid │ ├───────┼────────┼──────┼──────┼─────┼─────┼────────┤ │ (0,1) │ normal │ 920 │ 0 a │ │ │ (0,1) │ │ (0,2) │ normal │ 920 │ 0 a │ │ │ (0,2) │ │ (0,3) │ normal │ 920 │ 0 a │ │ │ (0,3) │ └───────┴────────┴──────┴──────┴─────┴─────┴────────┘ (3 rows) # SELECT * FROM index_page('accounts_pkey', 1); ┌────────────┬───────┬──────┐ │ itemoffset │ htid │ dead │ ├────────────┼───────┼──────┤ │ 1 │ (0,1) │ f │ │ 2 │ (0,2) │ f │ │ 3 │ (0,3) │ f │ └────────────┴───────┴──────┘ (3 rows) 然后进行如下更新语句，该语句 set 索引列但不更新索引列值:...

PostgreSQL Mentoring Program 是由 PostgreSQL 社区核心开发人员同时也是 EDB 首席数据科学家的 Robert Haas 发起的一项培养代码贡献者的计划。 在第一期的项目里，有 9 位 PostgreSQL Committer 自愿担任导师，对提交申请的代码贡献者进行一对一的指导。由于有 5 位 Committer 愿意同时指导 2 位同学，最终有 14 位申请者被选取。 在发起这项计划之前，Robert 在 PGConf.dev 2024 联合 Amit Langote, Masahiko Sawada, Melanie Plageman 进行了一个题为 Making PostgreSQL Hacking More Inclusive 的 Talk，社区希望越来越多的人参与到 PG 的代码开发当中。 这项计划对 Mentor 和 Mentee 的基本期望是二人至少每个月进行一次至少一小时的语音通话，在通话之前，Mentee 应该让 Mentor 知道他想谈论什么，Mentor 也会做一些相应的准备。在通话期间，Mentor 会尝试给 Mentee 一些有用的建议。Mentor 也会做一些其它的事情，比如 review Mentee 提交的 Patch，并私下进行沟通。两人中任何一方都可以随时出于任何原因或无原因结束导师关系，这时应该告诉该项目的组织者 Robert，他会进行进一步的安排。 除此之外，Robert 还创建了一个 Discord server，这个频道除了导师计划相关的人员，也有很多其他使用或开发 PG 的人员（后面有邀请链接），在这里除了可以讨论关于 PG 的任何话题之外，还有一个重要的事项是每月进行一次 PostgreSQL Hacking Workshop，当前的形式是相关人员提前分享一些关于 PG 内核的 Talk，然后组织线上会议进行深入讨论，每次会议都会有一到两个 committer 参加，考虑到有些人可能害怕自己的问题比较 silly 而不敢开口，会议不进行录制。...

本文纠正长久以来我对 OID(Object Identifiers) 的一个错误认知，我一直以为 OID 是全局唯一的，造成这个错误认知的原因之一是，在我刚接触 PostgreSQL 时看的一本书里相关的描述让我产生了这样的错觉。 我不确定其他人看这里的描述会不会跟我有一样的感觉，但即使我知道 create database 的时候会把 template 里的系统表进行拷贝，我的大脑依然自洽地认为 OID 是在每个 database 内全局唯一的，甚至在我看到 PG12 创建表 WITH OIDS 选项被删除 时，我的大脑也以 WITH OIDS 会导致 oid 被耗尽 的缘由把我说服了。 直到前段时间看 PG 文档 8.19. Object Identifier Types ，才让我开始质疑自己长久以来的错误认知: Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables....

PostgreSQL 在 2018 年首次出现在 Stack Overflow 开发者调查中，当时有 33% 的开发者报告说他们在使用它，相比之下，那一年最受欢迎的选项是 MySQL，有 59% 的开发者在使用。六年后，PostgreSQL 被 49% 的开发者使用，并且连续第二年成为最受欢迎的数据库。 https://survey.stackoverflow.co/2024/technology#most-popular-technologies-database 在所有的问卷中 48.7% 的开发者反馈在使用 PostgreSQL​，这一比例超过了 MySQL 的 40.3%。 在专业的开发者中，PostgreSQL 的使用比例超过了一半。 不过在学习编程维度和其它开发者中，MySQL 的使用比例占据第一的位置。 报告中还有另外一个维度: Admired: 红色，代表被赞美或被钦佩的程度 Desired: 蓝色，代表期望获得这项技能的程度 PostgreSQL 依旧一骑绝尘，另外报告指出 SQLite 的期望（Desired）得分从去年的第三上升到了第二位，超过了 MySQL。 相信 PostgreSQL 会越来越好，We ❤️ PG 🎊 也祝 MySQL 越来越好​ ⛽️

万圣节问题（Halloween Problem）是数据库系统中的一个现象，它指的是当一个查询检索了一组行，然后修改了其中一行或多行，修改后的行再次满足查询的条件，进而导致在相同的更新操作中再次访问该行。在某些情况下甚至可能导致无限循环。 这个问题最初是由 Don Chamberlin、Pat Selinger 和 Morton Astrahan 在 1976 年的万圣节那天发现，当时他们正在处理的一个查询本应给那些收入低于 25,000 美元的员工加薪 10%，但执行完成后，数据库中所有员工的收入都至少达到了 25,000 美元。这是由于更新过的记录也对查询执行引擎可见，并且继续符合查询条件，记录多次匹配，每次匹配都被加薪 10%，直到它们都超过 25,000 美元。 Halloween Problem 这个名字并没有描述问题的性质，仅仅是因为它被发现的那天恰好是万圣节🎃。 Pat and Morton discovered this problem on Halloween… I remember they came into my office and said, “Chamberlin, look at this. We have to make sure that when the optimizer is making a plan for processing an update, it doesn’t use an index that is based on the field that is being updated....

Postgres 在 x86 架构下的实例是否可以通过 pg_basebackup 同步到 arm 架构？ 在一个群里看到一个问题: pg_basebackup 是对 Postgres 实例数据文件在目的端的一个精确拷贝: pg_basebackup makes an exact copy of the database cluster’s files, while making sure the server is put into and out of backup mode automatically. 所以这个问题几乎等价于: x86 架构下的 pg 数据是否可以直接用 arm 架构下的 postgres 进程来管理？ 群里的讨论中出现了两种对立的观点: 一种认为字节序、对齐(padding)会导致不同架构数据格式的不兼容 一种认为理论上数据库的文件格式可以独立于 cpu 架构，存储格式的字节序跟 cpu 字节序没有直接关系 从 Postgres 的实现来说，第一种观点是正确的；但如果抛开 PG，第二种观点我认为也是一定成立的。 先说第二种观点: 其实这种观点是有依据的，我举一个例子: Parquet 是一种跨平台的数据存储格式，可以在不同的 CPU 架构上使用。这是因为 Parquet 的设计不依赖特定的硬件架构或操作系统，而是通过定义数据的存储结构和元数据来实现数据的高效读写和处理，并提供相关的库对数据进行序列化和反序列化。PG 生态中读写 Parquet 的 FDW 正是通过这些库来实现的。...

In memory of Simon Riggs. PostgreSQL 的核心贡献者 Simon Riggs 于 2024 年 3 月 26 日驾驶私人飞机在杜克斯福德机场坠毁，并在事故中丧生。 Simon 负责过许多 PostgreSQL 的企业级特性，包括时间点恢复（PITR）、热备份（hot standby）和同步复制（synchronous replication）。同时他也是 2ndQuadrant 的创始人，该公司雇佣了许多 PostgreSQL 的开发人员，并后来成为 EDB 的一部分，Simon 在 EDB 担任 Postgres Fellow 直到退休。 为了让更多的人了解或记住 Simon Riggs，这里分享一个 Josh Berkus 讲述的关于 Simon Riggs 有趣的故事。 – Start of the story – 2006~2008 期间，Josh Berkus 和 Simon Riggs 在 Greenplum 共事，一起合作开发 Greenplum 的资源管理系统。有一次，Simon Riggs 飞往加州的 San Rafael，在抵达的第一个晚上，合作伙伴们带他们去了一家冒充法式小酒馆的连锁餐厅，餐厅里有一个龙舌兰酒吧台，这是 Simon 第一次尝试龙舌兰（Josh 印象中 Simon 不太喜欢）。...