7月9日一个叫 pgrust 的项目在 GitHub 上引起了关注。它做的事情很直接用 Rust 重写 PostgreSQL而且宣称100% 通过了 PostgreSQL 原有的回归测试。PostgreSQL 的核心代码用 C 写了三十多年代码规模在 50 万行以上。用 Rust 重写整个数据库——不是写一个 Rust 客户端库而是把查询引擎、存储引擎、事务管理器、复制协议全部换掉——这件事听起来像是有生之年系列。但 pgrust 做到了跑通全部回归测试这值得认真看一下。为什么要用 Rust 重写 PostgresPostgreSQL 是用 C 写的这是一个事实。C 给 Postgres 带来了极致的性能和底层控制力但也带来了两个长期问题。一是内存安全。PostgreSQL 作为生产数据库代码审查和测试流程已经非常严格但 C 代码中的 use-after-free、缓冲区溢出之类的问题仍然会周期性出现。CVEs 列表里 Postgres 的安全公告不少与内存管理相关。这不是 Postgres 独有的问题——任何大型 C 项目都绕不开。二是维护门槛。PostgreSQL 的核心贡献者圈子相对稳定但能深入理解全部代码的新人越来越少。一个 50 万行的 C 代码库加上大量的宏定义和手动内存管理学习曲线非常陡峭。Rust 的所有权系统虽然也有学习成本但它至少从语言层面消除了很多 C 中需要靠经验来规避的陷阱。pgrust 的思路是把 Postgres 的核心逻辑用 Rust 重写一遍同时保留 Postgres 的 SQL 语法、客户端协议、工具链兼容性——让用户感觉不到底层换了语言。100% 回归测试通过意味着什么这个数据是项目的核心卖点也是最值得拆解的地方。PostgreSQL 的回归测试套件非常成熟经过三十年积累覆盖了 SQL 语法解析、查询优化、并发控制、数据完整性、复制、分区、JSON、全文搜索等几乎所有功能模块。能全部通过意味着在功能层面pgrust 已经实现了 Postgres 的完整语义。但这里有一个需要关注的区别回归测试覆盖功能正确性不覆盖性能特性。一个 Rust 重写版在查询逻辑上能返回和 C 版相同的结果不代表它在同样的硬件上能达到相同的吞吐量和延迟。不过换个角度看pgrust 的策略——以回归测试通过率为验证指标——是务实的。先把功能正确性确定下来再谈优化。这个顺序比先做性能优化再发现 bug 要合理得多。重写策略不是 FFI是替换pgrust 选择的是完整重写full rewrite而不是在 Rust 中通过 FFI 调用 C 模块。这意味着它需要自己实现 Postgres 的内存管理器、锁机制、进程模型等底层基础设施。从项目 README 的描述来看pgrust 利用了 Rust 的异步运行时来处理 I/O 和并发而不是直接移植 Postgres 传统的进程-per-connection 模型。这是 Rust 版本可以尝试的新方向——不用被 C 版本的历史设计决策限制。不过这也意味着 pgrust 和上游 Postgres 之间会有一个持续的追赶成本。PostgreSQL 社区每发布一个新版本pgrust 都需要分析变更、评估影响、做适配。这是一个长期维护工作不是写完就完事。对开发者和数据库生态的影响对大部分开发者来说pgrust 在现阶段的影响是潜在的而不是直接的。一个刚刚通过回归测试的项目距离生产部署还有巨大的距离——稳定性验证、性能调优、生态工具适配都需要时间。但它打开了一个值得关注的窗口如果 Rust 真的能在保持 PostgreSQL 兼容性的同时降低内存安全相关的风险数据库基础设施的底层技术选择就会多一个选项。目前数据库领域用 Rust 的案例在增加RisingWave、QuestDB 的部分组件、CockroachDB 的底层存储层etcd/raft 实现都在不同程度上使用了 Rust。但这些都是新数据库选用 Rust 实现。pgrust 走的是另一条路——替换已有数据库的实现语言。这条路更难。它要面对的不只是技术挑战还有社区信任——DBA 和生产运维团队凭什么相信一个用新语言重写的数据库和原版一样可靠对 Rust 语言本身来说pgrust 也是一个有价值的压力测试。PostgreSQL 的复杂性——混合了 OLTP 和 OLAP、支持多种索引类型、有复杂的锁和并发模型——是对 Rust 类型系统和异步生态的综合考验。pgrust 可能不会取代 PostgreSQL。但它正在做的实验——验证 Rust 能否承载一个 30 年积累的系统软件——本身就能回答很多关于 Rust 在基础设施领域适用性的问题。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版
7月9日一个叫 pgrust 的项目在 GitHub 上引起了关注。它做的事情很直接用 Rust 重写 PostgreSQL而且宣称100% 通过了 PostgreSQL 原有的回归测试。PostgreSQL 的核心代码用 C 写了三十多年代码规模在 50 万行以上。用 Rust 重写整个数据库——不是写一个 Rust 客户端库而是把查询引擎、存储引擎、事务管理器、复制协议全部换掉——这件事听起来像是有生之年系列。但 pgrust 做到了跑通全部回归测试这值得认真看一下。为什么要用 Rust 重写 PostgresPostgreSQL 是用 C 写的这是一个事实。C 给 Postgres 带来了极致的性能和底层控制力但也带来了两个长期问题。一是内存安全。PostgreSQL 作为生产数据库代码审查和测试流程已经非常严格但 C 代码中的 use-after-free、缓冲区溢出之类的问题仍然会周期性出现。CVEs 列表里 Postgres 的安全公告不少与内存管理相关。这不是 Postgres 独有的问题——任何大型 C 项目都绕不开。二是维护门槛。PostgreSQL 的核心贡献者圈子相对稳定但能深入理解全部代码的新人越来越少。一个 50 万行的 C 代码库加上大量的宏定义和手动内存管理学习曲线非常陡峭。Rust 的所有权系统虽然也有学习成本但它至少从语言层面消除了很多 C 中需要靠经验来规避的陷阱。pgrust 的思路是把 Postgres 的核心逻辑用 Rust 重写一遍同时保留 Postgres 的 SQL 语法、客户端协议、工具链兼容性——让用户感觉不到底层换了语言。100% 回归测试通过意味着什么这个数据是项目的核心卖点也是最值得拆解的地方。PostgreSQL 的回归测试套件非常成熟经过三十年积累覆盖了 SQL 语法解析、查询优化、并发控制、数据完整性、复制、分区、JSON、全文搜索等几乎所有功能模块。能全部通过意味着在功能层面pgrust 已经实现了 Postgres 的完整语义。但这里有一个需要关注的区别回归测试覆盖功能正确性不覆盖性能特性。一个 Rust 重写版在查询逻辑上能返回和 C 版相同的结果不代表它在同样的硬件上能达到相同的吞吐量和延迟。不过换个角度看pgrust 的策略——以回归测试通过率为验证指标——是务实的。先把功能正确性确定下来再谈优化。这个顺序比先做性能优化再发现 bug 要合理得多。重写策略不是 FFI是替换pgrust 选择的是完整重写full rewrite而不是在 Rust 中通过 FFI 调用 C 模块。这意味着它需要自己实现 Postgres 的内存管理器、锁机制、进程模型等底层基础设施。从项目 README 的描述来看pgrust 利用了 Rust 的异步运行时来处理 I/O 和并发而不是直接移植 Postgres 传统的进程-per-connection 模型。这是 Rust 版本可以尝试的新方向——不用被 C 版本的历史设计决策限制。不过这也意味着 pgrust 和上游 Postgres 之间会有一个持续的追赶成本。PostgreSQL 社区每发布一个新版本pgrust 都需要分析变更、评估影响、做适配。这是一个长期维护工作不是写完就完事。对开发者和数据库生态的影响对大部分开发者来说pgrust 在现阶段的影响是潜在的而不是直接的。一个刚刚通过回归测试的项目距离生产部署还有巨大的距离——稳定性验证、性能调优、生态工具适配都需要时间。但它打开了一个值得关注的窗口如果 Rust 真的能在保持 PostgreSQL 兼容性的同时降低内存安全相关的风险数据库基础设施的底层技术选择就会多一个选项。目前数据库领域用 Rust 的案例在增加RisingWave、QuestDB 的部分组件、CockroachDB 的底层存储层etcd/raft 实现都在不同程度上使用了 Rust。但这些都是新数据库选用 Rust 实现。pgrust 走的是另一条路——替换已有数据库的实现语言。这条路更难。它要面对的不只是技术挑战还有社区信任——DBA 和生产运维团队凭什么相信一个用新语言重写的数据库和原版一样可靠对 Rust 语言本身来说pgrust 也是一个有价值的压力测试。PostgreSQL 的复杂性——混合了 OLTP 和 OLAP、支持多种索引类型、有复杂的锁和并发模型——是对 Rust 类型系统和异步生态的综合考验。pgrust 可能不会取代 PostgreSQL。但它正在做的实验——验证 Rust 能否承载一个 30 年积累的系统软件——本身就能回答很多关于 Rust 在基础设施领域适用性的问题。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版
双梁正问题 【 torch 实战】（Python代码实现）)
