AWS RD是否提供有关故障转移或硬件配置期间OID稳定性的任何保证？
我之所以问这个，是因为在测试本地Postgres数据库时，我丢弃并重新创建了包含citext类型列的数据库并遇到了错误The field 'name' has a type currently unknown to Npgsql (OID 1393966)。我意识到这是因为在数据库下降和创建中，OID并未持续存在，而NPGSQL caches列类型OID。
我是Azure和AWS的新手，但是我发现Azure Connections是不可靠的，因为它可以将数据库"透明地"调整给客户端。我不确定AWS是否具有类似的行为，但是我已经阅读了区域之间的故障。我担心出于任何原因透明地切换服务器可能会更改citext的OID并导致应用程序开始失败 - 或更糟糕的是在OID碰撞的机会上的行为错误。
我的恐惧是没有根据的吗？是否有一种检测连接开关和调用连接的方法。RELOADTYPES((？
postgresql通常不能保证通过扩展名创建的类型的类型稳定性(与稳定的内置类型相反(。afaik通常在Postgresql中，而不仅仅是RDS。
这是NPGSQL加载类型按名称的原因之一 - 它首次连接到给定数据库(或更准确地说，或更确切地说，到给定的连接字符串(，所有类型都已加载和已知的类型名称(例如citext(与该名称的特定数据库类型匹配。此信息在应用程序寿命的连接字符串上被缓存。
如果在应用程序的寿命中，类型OID会更改(因为该类型的扩展名被删除并重新创建(，则确实必须调用NpgsqlConnection.ReloadTypes()才能重新加载名称/OID信息。
您关于失败的问题确实很有趣...我对RD的实现失败一无所知，但是您实际上看到了两个地理实例中的Citext类型OID不同吗？
因此，通过一些实验，OID似乎可以稳定。
我每100ms进行以下查询：
select typname, oid, pg_postmaster_start_time(), inet_server_addr()::text
from pg_catalog.pg_type
where typname = 'citext';
每当任何结果更改时都记录下来。然后，我重新启动了我的RDS实例。经过几个连接超时后，INET_SERVER_ADDR((更改了，但OID没有。我再次重新启动，inet_server_addr((恢复了，OID再次保持不变。
除非任何人都可以确定证明OID改变或知道内部实施细节，否则我现在相信OID在失败期间稳定 - 但是我犹豫不决地说我已经证明了这一点，只是因为我没有证明这一点相反的