只要你保持你发出这些后续查询的连接，你计划做的事情是安全的-在pool_mode=transaction中，你可以通过发出begin;并以commit;结束来开始你的临时工作。确保使用on commit drop创建临时对象，除非你的池在连接释放时可以discard它们。Pgbouncer默认情况下这样做。
临时对象是可见的，并且只能由创建它们的会话/连接访问，它们存在于它们的私有pg_temp_NNN模式中。如果您获取连接create temp table，释放连接并请求另一个连接，则不能保证获得相同的连接，其中包含该临时对象。如果不将您的工作 Package 在begin;...commit;中，pgbouncer会假设每个语句都可以在自己的事务中运行，所以每次都可以自由地将您的连接交换为不同的连接，就像您在pool_mode=statement中一样（autocommit 行为）。
临时表正在下降，如果我采取（另一个？）连接时，我将使用第二个执行语句
根据池的不同，它可能会被删除，也可能不会被删除，但你可能会在创建后立即看不到它，因为如果你的初始连接被释放，然后你得到了一个新的连接，临时对象仍然在旧的连接中。同时，其他一些工作者可能会意外地从池中获取连接，该临时对象仍然存在。
如果考虑temp对象是因为性能，如果您认为它们可以在并发工作进程中重用表名而不会导致名称冲突（临时进程通过将其自身安装在特定于会话的pg_temp_NNN模式中来实现），则可以设置自己的特定于工作进程的模式，并使用模式限定标识符来引用这些表（或者在pgbouncer可以跟踪的search_path前面加上模式名）将它们放在那里：

create schema my_worker_123_schema;
create unlogged table my_worker_123_schema.my_unlogged_table;

字符串
无论这两个语句最终是否在不同的连接和事务中运行，结果表都将持续存在，并且对所有未来的连接都是可见的。

drop schema my_worker_123_schema cascade;

型