gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-11-29 12:52:53 25 4
gpt4 key购买 nike

是否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/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com