我目前在生产环境中运行 PostgreSQL 9.4，但我们正在服务器上进行操作系统升级，因此我认为可能是时候将 PostgreSQL 版本升级到最新版本 (12)，以便我可以利用一些可用的新功能。然而，各个数据库中的一些表是很久以前构建的（例如，2008 年之前，至少在某些情况下很可能是 2000 年之前）。这些数据库包含许多使用 OID 的表（WITH OIDS=TRUE在定义中）。
此外，我还对大部分代码库进行了搜索，以查找任何表中对 OID 列的引用，并发现了几个实例，其中存在显式调用 OID 列的查询。幸运的是，这样的情况并不多，而且大多数都是引用系统表（即，SELECT oid FROM pg_namespace，...FROM pg_class）。
对从 9.4 数据库转储的数据运行pg_upgrade该过程会在此时停止，并断然声明直到数据库中没有 OID 后才会继续。据我所知，他们在过去的几个版本中一直在慢慢地逐步淘汰这些内容，而 12 版本使它们基本上变得无关紧要，但建议是在pg_upgrade继续之前完全删除 OID 列。我认为这对于一个几乎不相关的专栏来说是“矫枉过正”。
此时 - 我承认我还没有完全考虑到这一点 - 我想知道简单地“翻转”WITH OIDS受影响的表定义中的开关是否FALSE足以继续升级？如果翻转的话，现有的 OID 列是否仍是数据库结构的一部分（我认为会，但自动升级可以做一些有趣的事情）？
我意识到，在理想情况下，我希望最终从数据库中完全消除 OID。然而，作为一个单人 IT 部门，这必须“列入清单”以供以后评估。目前，我只是想让数据库在最新的 PostgreSQL 版本上启动并运行，同时我有机会这样做而不会立即影响操作。
我有一个在远程托管 VM 服务器 (Windows Server 2019) 上运行的 PostgreSQL 12.1 数据库系统（我将其称为 PGSQL）。几个月前我们升级了服务器操作系统和 PGSQL。从那时起，一切都或多或少地正常运行，直到今天早上，我开始在几乎每个连接到此 PGSQL 实例的内部应用程序中收到上述数据库错误。
为了检查连接，我运行了SELECT * FROM pg_stat_activity;，它返回了 103 行。我的postgresql.conf文件有max_connections = 100，所以这是有道理的，但没有意义的是，在这 103 个连接中，其中 90 多个连接被idle列为DISCARD ALL. 所有这些都显示为由同一非超级用户帐户从服务器自己的内部地址执行。但是，一些连接显示query_start一个月或更长时间前的日期值。
现在，不幸的是，我们现有的许多应用程序都是使用硬编码凭据构建的（我对继承的这些应用程序的代码有很多“清理”工作要做），并且通常是从指向的快捷方式执行的到托管 PGSQL 数据库的服务器上的“应用程序”共享，因此所有这些看起来都不是特别“可疑”。我试图简单地终止使用前一个查询中的值SELECT pg_cancel_backend(<pid>);之一的进程pid，但重新查询pg_stat_activity仍然在结果集中显示相同的记录（据我所知，所有值似乎完全相同）。
也许我没有使用正确的函数来终止这些“挂起”的进程或其他东西，但我无法弄清楚如何单独清除这些连接。因为我需要让我们的生产环境恢复到可用状态，所以我最终只是停止并重新启动服务器上的 PGSQL 服务，这确实清除了所有旧的DISCARD ALL语句，但我很好奇是否可以采取一些措施来防止这种积压的“挂”报表日后出现。
我的问题是，我怎样才能防止这种情况再次发生？需要注意的一件事是，在将 PGSQL 服务器升级到 v12.1 之前，我们运行了 v9.4 多年，并且从未遇到过此问题。我想知道是否有较新版本的 PGSQL 固有的问题，或者甚至可能是在 Windows Server 2019 环境中运行 PGSQL 的问题导致了此行为。
为了参考和整理，以下信息来自评论：
我没有任何服务器端用于管理连接池（我在有关PgBouncer的其他问题中看到了一些参考资料，但还没有机会查看它是否对我们的环境有帮助）。我的大多数应用程序都通过Npgsql …