是否AWS RDS在故障转移或硬件配置期间对 OID 的稳定性提供任何保证？
我问这个是因为在测试本地 Postgres 数据库时，我删除并重新创建了包含 citext 类型列的数据库并遇到错误 The field 'name' has a type目前 Npgsql 未知(OID 1393966)。我意识到这是因为 OID 不会在数据库删除和创建过程中持续存在，并且 Npgsql caches column type OIDs .
我是 Azure 和 AWS 的新手，但我发现 Azure 连接不可靠，因为它可以对客户端“透明地”移动数据库。我不确定 AWS 是否有类似的行为，但我读过区域之间的故障转移是透明的。我担心出于任何原因透明地切换服务器可能会更改 citext 的 OID 并导致应用程序开始失败 - 或者更糟的是在 OID 冲突的机会上出现错误行为。
我的恐惧是没有根据的吗？有没有办法检测连接开关并调用Connection.ReloadTypes() ？
最佳答案
PostgreSQL 通常不保证由扩展创建的类型的类型 OID 稳定性(与稳定的内置类型相反)。据我所知，PostgreSQL 通常就是这种情况，而不仅仅是 RDS。
这就是 Npgsql 按名称 加载类型的一个原因 - 第一次连接到给定数据库(或更准确地说，连接到给定连接字符串)时，所有类型都被加载并且已知类型名称(例如 citext)与该名称的特定数据库类型 OID 相匹配。此信息在应用程序的生命周期内缓存在连接字符串中。
如果在应用程序的生命周期中，类型 OID 发生变化(因为该类型的扩展被删除并重新创建)，那么确实必须调用 NpgsqlConnection.ReloadTypes() 来重新加载名称/OID信息。
您关于失败的问题确实很有趣...我对 RDS 如何实现其故障转移一无所知，但您是否真的看到 citext 类型 OID 在两个地理实例之间有所不同？
关于postgresql - 故障转移期间 AWS Postgres OID 的稳定性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49990563/