• 我不得不删除我之前的答案，因为我最初使用的是pgAdmin，它显然非常热衷于固定连接。这意味着我不能信任我的数据。我用另一个性能更好的工具psql重做了这个实验。*

我明白你的意思。根据文档，SET会导致钉扎，但不清楚这是否包括SET LOCAL。因为我也需要这些信息，我今天将运行一个测试，并在这里发布结果。

我将执行以下操作

步骤1：通过我们的代理打开一个连接，并使用常规的SET，以确保DatabaseConnectionsCurrentlySessionPinned指标增加到1。

SET search_path TO blah;
SET app.tenant_id TO 123;

第2步：我将关闭该连接，并看到指标降回到0。
步骤3：我将打开一个新连接，但这次我将使用以下查询：

SET LOCAL search_path TO blah;
SET LOCAL app.tenant_id TO 123;

第4步：我将关闭连接，如果连接被固定，我将监视指标，看看它是否以及何时会减回0。

让我们开始吧

• 警告 *：不要查看RDS管理控制台中的指标。请参阅：https://repost.aws/questions/QUfPWoiFxmR7-lios5NrFwBA/fix-database-connections-currently-session-pinned-metric-on-rds-proxy-dashboard
• 步骤1 *

正如预期的那样，当我运行SET命令时，代理和服务器之间的连接立即被固定。

• 第二步 *

当我关闭客户端和代理之间的连接时，代理和服务器之间的固定连接立即关闭。

• 第三步 *

当我运行SET LOCAL命令时，代理和服务器之间的连接没有固定。

• 第四步 *

连接未固定，因此此步骤是多余的。

结论

SET LOCAL确实避免了RDS代理中的固定，但警告必须在事务中完成。
在我之前尝试回答这个问题时，pgAdmin的行为使我得出结论，在这两种情况下都会发生固定，这是错误的。
为了回答您的其他问题，如果发生了固定，则事务是否短并不重要。服务器连接将保持固定，直到客户端连接消失。唯一的解决办法是确保在客户端连接固定后立即关闭它们。
该文档指出，"当连接被固定时，每个后续事务使用相同的底层数据库连接，直到会话结束。其他客户端连接也不能重用该数据库连接，直到会话结束。当客户端连接断开时，会话结束。"