Jeremy Schneider：Postgres检查点后续与排序规则可视化及Codex Luna
内容提要
本文讨论了PostgreSQL中checkpoint_timeout设置对高可用性的影响，指出即使有HA副本，若主库重启耗时过长，副本也可能面临同样问题，因此建议保持默认值以确保稳健性。随后介绍了Postgres排序规则更新项目，包括使用Docker和GitHub Actions进行测试，并提及使用OpenAI Codex的Luna模型以低成本高效完成项目，展示了其性价比。
延伸解读
HA副本并非万能保险
文章指出，即使有高可用副本，增大checkpoint_timeout仍可能带来风险。因为主库的检查点会直接转化为副本的重启点，若副本也发生重启，同样需要长时间恢复。此外，自动化工具或人为失误可能导致副本意外重启，甚至查询触发bug导致OOM重启，这些情况下副本无法提供快速恢复。因此，保持默认值更稳健。
排序规则性能差异显著
文章提到，在排序2500万字符串时，glibc 2.28+版本对德语、英语、法语等语言性能极差，耗时长达2小时，而韩语、日语和C排序仍保持高效。这提示在特定语言环境下，排序性能可能成为瓶颈，需关注glibc版本对排序的影响。
低成本AI代理的实践
作者使用OpenAI Codex的Luna模型（低努力模式）完成了与之前花费数百美元项目复杂度相当的排序规则更新项目，仅消耗$20订阅的少量配额。Luna表现出色，未出现重大错误，但需仔细审查代码，因为存在细微错误（如混淆POSIX和C排序规则）。这表明低成本AI代理在特定任务中具有高性价比。
Q&A
为什么即使有HA副本，也不建议将PostgreSQL的checkpoint_timeout设置得过大？
因为如果主库因故障需要重启，且checkpoint_timeout设置得很大（如45分钟），主库恢复可能需要很长时间。虽然可以提升副本而不重启，但副本也会因为同样的WAL流而需要相同的重启时间。此外，自动化工具或人为错误可能导致副本意外重启，从而无法快速恢复。因此，保持默认值5分钟更稳健。
Postgres排序规则更新项目使用了哪些工具和技术？
该项目使用Docker和GitHub Actions进行测试，并利用OpenAI Codex的Luna模型（低努力设置）来辅助开发，以低成本高效完成项目。
在Postgres排序规则测试中，哪些语言的排序性能在glibc 2.28+版本中严重下降？
德语、英语、法语、西班牙语、俄语、阿拉伯语和中文的排序时间在glibc 2.28+版本中飙升到2小时（针对2500万字符串），只有韩语、日语和C排序保持高效。
作者为什么从Anthropic的Claude切换到OpenAI的Codex？
因为作者在使用Claude时，会话突然触发安全护栏，无法继续处理Postgres相关项目，且无法解决。而Codex目前较少出现此类问题，因此切换。
使用Luna模型完成排序规则更新项目的成本效益如何？
作者在$20的订阅计划上使用Luna（低努力设置）完成了与之前花费数百美元项目复杂度相当的工作，且Luna的token价格远低于Terra，每周配额消耗很少，性价比极高。
排序规则更新项目如何实现自动监控未来的变化？
通过GitHub Actions工作流每两周自动运行一次，检查Debian SID的校验和变化，并在表格上方显示徽章，绿色表示数据准确，从而提供未来变化的实时指示。
