PostgreSQL 17.5中孤儿pg_temp_#与pg_toast_temp_#架构导致EF+dotConnect模型更新失败，求助溯源及解决

各位好，我目前遇到一个升级PostgreSQL后才出现的棘手问题，想请教下大家的排查思路和解决方案：

环境背景 #

我用的是PostgreSQL 17.5（EDB社区版，Windows系统），ORM采用Entity Framework搭配Devart的dotConnect for PostgreSQL。之前在PG 13.18版本下用完全相同的ORM和dotConnect组件，一切正常，但升级到17.5后出现了严重的模型更新阻塞问题。

问题现象 #

数据库里逐渐堆积了大量的pg_temp_###和pg_toast_temp_###孤儿架构（编号###从1一直到max_connections的设置值），而且这些架构都是空的——我用下面的SQL查询过，里面没有任何对象：

SELECT c.relname, c.relkind 
FROM pg_catalog.pg_class c 
JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace 
WHERE nspname like '%pg_temp_%' OR nspname like '%pg_toast_temp_%';

这些空架构直接导致EF的「Update Model From Database」操作彻底卡住：ORM发送的那个用来枚举所有表、列、视图的大查询根本跑不完。我试过手动执行类似DROP SCHEMA IF EXISTS pg_toast_temp_497; DROP SCHEMA IF EXISTS pg_temp_497;的命令删掉所有孤儿架构，问题会暂时解决，但过段时间这些架构又会慢慢冒出来。

已做的排查 #

我参考了Laurenz Albe在相关问题里的建议，逐一排查了几个常见方向：

• 系统中没有长时间运行的会话或查询；
• 我们自己的业务代码创建临时表时，都明确指定了ON COMMIT DROP；
• 不存在用户手动创建临时表后不清理的场景。

另外还发现两个有意思的线索：

• pg_temp_###和pg_toast_temp_###的数量总是一一对应的，是不是创建临时表时一定会成对生成这两种架构？
• 架构的编号范围刚好覆盖了从1到max_connections的所有值，感觉和连接数上限强相关。

我还拆解了ORM卡住的那个大查询，发现瓶颈集中在UnionAll2（由Extent7和Extent8合并的部分）。对比不同环境的执行情况：

• PG13.18+404个命名空间：查询几分钟内完成；
• PG17.5+4个命名空间：4分钟左右完成；
• PG17.5+1004个命名空间：完全跑不完。

求助问题 #

现在我想搞清楚两个核心问题：

1. 除了临时表未正确清理、长会话之外，还有什么原因会导致这类空的孤儿pg_temp/pg_toast_temp架构堆积？
2. 有没有不用全量日志所有PostgreSQL命令（逐个检查每个临时表是否带ON COMMIT DROP）的方法，能快速定位到这些孤儿架构的来源？

内容来源于stack exchange