笔记
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 解析器处理 SET 语句和 LISTEN/NOTIFY，以及利用 Tokio 多线程架构，解决传统连接池的漏桶抽象问题。
背景：为什么还需要一个新的连接池？
在 Postgres 生态中，连接池工具已经有很多成熟的选择，比如 PgBouncer、RDS Proxy、Pgpool-II、Supavisor 等。它们都遵循 Unix 哲学——只做一件事并做好它。PgBouncer 之所以流行，正是因为它简单可靠。然而，这种简单性引入了一个业界称为“漏桶抽象”（Leaky Abstraction）的问题：当你部署一个连接池时，你很快会发现它改变了你使用数据库的方式，要求你做出权衡，甚至修改应用代码。
对于已经运行了一段时间的应用——这往往是需要连接池的场景——修改生产代码可能意味着改动数千行代码，而且这些代码通常缺乏充分的测试覆盖。PgDog 的目标就是消除这种痛苦。
连接状态泄漏：SET 语句的困境
连接池的核心机制是复用数据库连接。当一个客户端执行完查询后，连接会被归还给池子，供下一个客户端使用。但问题在于：Postgres 的连接状态是会话级别的。如果客户端 A 执行了 SET statement_timeout TO '5m'，然后释放连接，客户端 B 拿到这个连接后，它的 statement_timeout 也变成了 5 分钟。
最坏的情况下，如果客户端 B 依赖于会话变量来实现行级安全（Row Level Security, RLS），那么由于状态泄漏，RLS 策略可能失效，导致数据行“静默消失”。更常见的情况是，一个慢查询因为继承了过长的超时设置，引发数据库事故。
传统的建议是：迁移到连接池后，就不要再使用 SET 语句了。但 SET 是 Postgres 的原生功能，如果你不能使用它，意味着你牺牲了功能完整性，必须改变应用编写方式。如果你用 SET 来实现 RLS，你甚至根本无法使用连接池。
PgDog 的解决方案：内置 SQL 解析器
PgDog 自带一个 SQL 解析器，能够检测出 SET 语句，提取变量名和值，并将它们存储在每个客户端连接的代理端。当客户端执行查询时，PgDog 首先检查该客户端的会话状态是否与服务器端匹配。如果不匹配，它会自动执行一系列 SET 语句来同步状态。
这个检测算法非常快。如果多个变量需要更新，PgDog 使用查询流水线（query pipelining）在一次网络往返中完成所有更新。这样性能影响极小，而你仍然可以继续使用 SET 这个 Postgres 原生功能，无需修改应用代码。
LISTEN/NOTIFY：发布/订阅的代理
LISTEN 和 NOTIFY 是 Postgres 内置的发布/订阅机制。你可以在一个会话中执行 LISTEN channel 监听某个频道，然后在另一个会话中执行 NOTIFY channel, 'message' 发送消息。这是一个很简洁的功能，但同样在连接池的“事务模式”下失效了——因为连接被复用，监听状态会丢失。
许多开发者因此被迫迁移到 SQS 或 Redis 来实现 pub/sub。PgDog 让 LISTEN/NOTIFY 也能正常工作。它在内部处理这两个命令，并在多个 PgDog 进程之间传递消息。对客户端来说，PgDog 看起来就是消息代理，但实际上后端仍然是 Postgres。
PgDog 还保证了 NOTIFY 的事务语义——即使在边缘情况下（比如某些导致数据库崩溃的用法），它也能正确处理。内部实现上，PgDog 使用 Tokio 的广播通道（broadcast channel）在同一个进程内的客户端之间传递消息。为了支持多进程（例如生产环境中运行多个容器），它还通过一个专用连接将所有 LISTEN 和 NOTIFY 命令发送到 Postgres。这样，PgDog 本身就像一个 pub/sub 客户端，代理着其他 pub/sub 客户端，而 Postgres 仍然是实际的消息中枢。
多线程架构：应对高并发与突发流量
PgDog 基于 Tokio（一个 Rust 异步运行时）构建，采用多线程工作模式。每个客户端由一个独立的异步任务处理，任务数量与连接数线性相关。多线程让 PgDog 可以充分利用多核 CPU，从单个进程服务更多客户端和每秒更多查询。
相比之下，PgBouncer（即使支持 SO_REUSEPORT）和 RDS Proxy（即使有“无服务器”自动扩缩容）都存在一个根本问题：每个代理进程拥有自己独立的 Postgres 连接池，客户端一旦连接到某个实例，就无法切换。如果某个实例过载，所有连接到它的客户端都会卡住。
PgDog 的多线程架构使得单个进程可以处理更多流量，从而用更少的服务器连接池化更多客户端，提高了连接利用率和效率。多线程进程也能更好地处理突发查询峰值，因为它们不需要等待自动扩缩容。如果你的应用有延迟 SLA，你不希望代理成为瓶颈。
此外，多线程进程的管理手册也更简单：只需要一个指标来源和健康检查点，无需将复杂性推到难以调试的地方，比如 Linux 内核或 AWS RDS 控制平面。
总结
替换像 PgBouncer 这样已有 20 年历史的项目并不容易，但 PgDog 团队认为，当现有方案存在根本性缺陷时，值得去修复。PgDog 已经在生产环境中运行超过一年，以每秒 200 万次查询的速率进行连接池化。它完全开源，你可以自由使用和修改，并可以部署在任何地方。
原文链接：https://pgdog.dev/blog/why-yet-another-connection-pooler