笔记
0工具
0此页用于记录用户反馈问题后的每一次改进
关于
“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
不想公开、只想临时给人看：点“分享”生成一条带密码和有效期的链接，到期自动失效，你也能随时撤销。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
PgDog：一个让Postgres连接池不再“泄漏”的新选择
本文介绍PgDog如何通过SQL解析、状态同步和多线程架构，解决传统Postgres连接池工具（如PgBouncer）带来的“泄漏抽象”问题，让SET命令和LISTEN/NOTIFY等原生特性在连接池环境下正常工作。
为什么又造一个连接池轮子？
Postgres生态中已有多个成熟的连接池工具，最知名的包括：
- PgBouncer：轻量级、单线程、广泛使用
- RDS Proxy：AWS托管服务，支持自动扩缩
- Pgpool-II：功能丰富但配置复杂
- Supavisor：Supabase团队开发的现代连接池
这些工具都遵循UNIX哲学——“只做一件事，并做到极致”。PgBouncer之所以流行，正是因为它简单可靠。然而，作者认为这种设计引入了一个“泄漏抽象”（leaky abstraction）：当你部署连接池后，会立刻意识到数据库的使用方式被迫改变。
泄漏抽象的核心问题
1. 连接状态管理（SET命令）
连接池会复用Postgres连接。当一个客户端执行SET命令修改会话变量后，如果连接被分配给另一个客户端，前一个客户端的设置就会“泄漏”到新客户端。
典型场景：
sql
SET statement_timeout TO '5m';
SELECT * FROM users WHERE banned IS true;
在生产环境中，这可能导致：
- 慢查询意外获得过长执行时间，引发数据库事故
- 依赖会话变量的行级安全（RLS）策略失效，数据行“静默消失”
传统解决方案：官方建议“不要使用SET”。但这意味着你不得不修改大量应用代码，甚至放弃某些Postgres原生功能。
2. LISTEN/NOTIFY（发布/订阅）
LISTEN/NOTIFY是Postgres内置的轻量级消息队列。在事务模式下使用连接池时，这个功能会失效——因为连接被复用后，监听状态无法保持。很多开发者因此被迫迁移到SQS或Redis。
PgDog的解决方案
1. 智能SET处理
PgDog内置了一个SQL解析器，可以：
- 检测客户端的SET语句，提取变量名和值
- 在每个客户端连接上独立存储会话状态
- 当客户端执行查询前，自动检查当前服务器状态是否匹配客户端的会话状态
- 若不匹配，自动执行SET语句同步状态
性能优化：如果多个变量需要同步，PgDog使用查询流水线（query pipelining）一次性完成所有SET操作，只需一次网络往返。这使得性能开销极小。
2. LISTEN/NOTIFY的原生支持
PgDog在代理层内部处理这两个命令：
- 同一PgDog进程内：使用Tokio的广播通道（broadcast channel）在客户端之间传递消息
- 多进程场景（例如生产环境中的多个容器）：通过一条专用连接将LISTEN/NOTIFY命令发送到真实Postgres，让Postgres作为实际的“消息代理”
这样，客户端看到的是PgDog在扮演消息代理，但底层依然是Postgres在管理消息。PgDog还完整保留了NOTIFY的事务语义——包括那些曾让某些团队搞垮数据库的边界情况（作者表示已修复）。
3. 多线程架构
PgDog基于Tokio（Rust异步运行时）构建，采用多线程工作模式：
- 每个客户端对应一个独立的异步任务，连接数增加时线性扩展
- 充分利用多核CPU，单进程即可处理更多客户端和更高QPS
与传统工具的对比：
- PgBouncer支持
SO_REUSEPORT，RDS Proxy支持“无服务器”自动扩缩，但它们都需要分片连接池——每个代理进程有独立的Postgres连接池，客户端一旦连接就无法切换实例。某个进程过载时，所有连接该进程的客户端都会被阻塞。 - PgDog的多线程设计让单个进程能处理突发流量，无需等待自动扩缩，对延迟敏感的应用程序更友好。
- 运维更简单：只需监控一个进程的指标和健康检查，无需将复杂度推入Linux内核或AWS RDS控制平面。
性能与现状
PgDog已在生产环境运行超过一年，在每秒200万次查询的负载下稳定工作。它是完全开源的自由软件，可部署在任何地方。
总结
PgDog的核心创新在于：不要求用户为连接池改变应用代码。它通过智能的会话状态管理、原生的消息队列支持和多线程架构，填补了传统连接池工具的空白。如果你因为连接池而不得不放弃SET命令或LISTEN/NOTIFY，或者受困于单线程代理的性能瓶颈，PgDog提供了一个值得关注的替代方案。
原文链接：https://pgdog.dev/blog/why-yet-another-connection-pooler