Skip to content

Supavisor and Connection Terminology Explained

我得承认，Postgres 社区的官方命名规范确实有点令人困惑，所以这里做一个基本的概述。有点长，所以你可以直接跳到和你相关的部分：

🌐 I'll be the first to admit that the official naming conventions in the Postgres community can be a bit confusing, so here's a basic rundown. It's a bit long, so feel free to jump to the portion relevant to you:

客户： #

🌐 Clients:

这是任何尝试连接到连接池或数据库的服务器。这可能会让人困惑，因为在其他情况下，‘客户端’一词也意味着通过前端连接的用户。

🌐 This is any server trying to connect to the pooler or database. This can be confusing because the term client in other scenarios also means users connecting through a frontend.

客户端连接： #

🌐 Client connections:

一个应用服务器可以创建多个连接。客户端连接表示服务器与连接池建立的任何连接。

🌐 A single application server can create multiple connections. A client connection represents any connection established by a server to the pooler.

直接/数据库连接： #

🌐 Direct/database connections:

这表示与数据库的直接连接。

🌐 This represents a direct connection to the database.

你的应用服务器可以直接使用数据库连接字符串连接：

🌐 Your application servers can directly connect using the DB connection string:

1
postgresql://postgres:[PASSWORD]@db.[PROJECT REF].supabase.co:5432/postgres

通过连接池器时，它会代表客户端建立数据库/直接连接。然后，它会将客户端连接的请求转发/分流到数据库/直接连接。

🌐 When connecting through the pooler, it will establish db/direct connections on behalf of clients. It then forwards/triages requests from client connections to db/direct connections.

最大连接数： #

🌐 Max_connections:

通过配置 max_connections 系统变量，它表示 Postgres 可以容忍的直接/数据库连接数。你可以通过运行这个 SQL 来查看你的实例设置：

🌐 Configured with the max_connections system variable, it represents how many direct/database connections Postgres will tolerate. You can view your instance's settings by running this SQL:

1
SHOW max_connections;

想要了解更多关于配置此值的信息，请查看监控连接故障排除指南。

🌐 To know more about configuring this value, check out monitoring connections troubleshooting guide.

泳池大小： #

🌐 Pool size:

Supavisor 被允许从数据库请求的直接连接数量，用于管理每个 数据库/角色/模式组合。

🌐 The number of direct connections Supavisor is permitted to request from the database to manage each database/role/mode combination.

交易模式： #

🌐 Transaction mode:

事务模式允许连接池在多个客户端之间共享直接连接。当连接池连接字符串监听端口 6543 时使用它：

🌐 Transaction mode gives the pooler permission to share direct connections among multiple clients. It is used when the pooler connection string is listening on port 6543:

1
#example transaction mode string
2
postgres://postgres.obfwhevidiamwdwki:[YPASSWORD]@aws-0-ca-central-1.pooler.supabase.com:**6543**/postgres

Postgres 连接使用的是 Postgres Wire Protocol（PWP），而不是 HTTP。PWP 有点像 WebSocket：一旦建立连接，它就会保持开启并处于活跃状态，直到客户端断开连接。

🌐 Postgres connections use the Postgres Wire Protocol (PWP) rather than HTTP. PWP acts like a WebSocket: once a connection is made, it stays open and active until the client disconnects.

如果空闲或贪婪的客户端占用了太多连接，其他应用服务器就无法连接到你的数据库。事务模式可以帮助避免这个问题，它只允许客户端在执行查询时访问数据库连接。这样就减少了达到最大直接连接数的可能性。

🌐 If too many connections are held by idle or greedy clients, other application servers won’t be able to connect to your database. Transaction mode helps avoid this problem by allowing clients to access the database connections only when they are running a query. This reduces the chances of hitting the maximum direct connection limit.

会话模式： #

🌐 Session mode:

会话模式会限制连接池，迫使它将底层直接连接仅授予单个客户端连接。

🌐 session mode restricts the pooler, forcing it to grant an underlying direct connection exclusively to a single client connection.

1
#example session mode string | uses port 5432
2
postgres://postgres.obfwhevidiamwdwki:[YPASSWORD]@aws-0-ca-central-1.pooler.supabase.com:**5432**/postgres

会话模式的行为几乎和标准的直接连接一样，让人不禁想：那有啥用呢？

🌐 Session mode behaves nearly identically to a standard direct connection, which makes one wonder: what is the point?

一个好处是，如果你在仅有IPv4的环境中需要持久连接又不想启用IPv4附加功能，会话模式可以解决这个问题。

🌐 One benefit is that if you need long-lasting connections in an IPv4-only environment and do not want to enable the IPv4 Add-On, session mode resolves this issue.

另一个明显的好处是排队。如果所有直接连接都被占用，没有连接池的话，第 n+1 个试图连接的客户端会被拒绝。它不得不不断查询数据库看看是否有空位。会话模式下的连接池会把客户端排队等待最多一分钟，这样它就不必在等待空位时不断查询了。

🌐 Another clear benefit is queueing. If all direct connections were taken, without the pooler, the n+1 client that tried to connect would be rejected. It would have to constantly poll the database to see if a slot became available. The pooler in session mode will queue a client for up to a minute, so it doesn't have to constantly poll while waiting for a slot.