Question

AWS RDS是否在故障转移或硬件配置期间提供有关OID稳定性的任何保证？

我问这个是因为在测试本地Postgres数据库时，我删除并重新创建了包含citext类型列的数据库，并遇到错误The field 'name' has a type currently unknown to Npgsql (OID 1393966)。我意识到这是因为OID不会在数据库丢弃和创建之间持久化，并且Npgsql caches column type OIDs。

我是Azure和AWS的新手，但我发现Azure连接不可靠，因为它可以“透明地”向客户端移动数据库。我不确定AWS是否有类似的行为，但我读过区域之间的故障转移是透明的。我担心由于任何原因透明地切换服务器可能会改变citext的OID并导致应用程序开始失败 - 或者更糟糕的是OID冲突的机会有错误的行为。

我的恐惧没有根据吗？有没有办法检测连接开关并拨打Connection.ReloadTypes()？

Answer 1

PostgreSQL通常不保证扩展创建的类型的OID稳定性（与稳定的内置类型相反）。 AFAIK一般就是PostgreSQL中的情况，而不仅仅是RDS。

这就是为什么Npgsql按名称加载类型的原因之一 - 第一次连接到给定数据库（或者更准确地说，连接到给定的连接字符串）时，所有类型都被加载并且已知类型名称（例如citext）与该名称的特定数据库的类型OID匹配。此信息缓存在应用程序生命周期的连接字符串中。

如果在应用程序的生命周期中，类型OID发生更改（因为该类型的扩展名已被删除并重新创建），则确实必须调用NpgsqlConnection.ReloadTypes()来重新加载名称/ OID信息。

关于失败的问题确实很有意思......我对RDS如何实现其故障转移一无所知，但您是否真的看到过两个地理实例的citext类型OID不同？

Answer 2

通过一些实验，似乎OID可以稳定。

我每100毫秒运行以下查询：

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在故障转移过程中是稳定的 - 但是我很犹豫地说我已经证明它只是因为我没有证明相反的事情

故障转移期间的AWS Postgres OID稳定性

2 个答案: