将列从时间戳更改为时间戳会锁定表吗？

Question

我想将列从timestamp （无时区）迁移到timestamptz类型。

我正在使用Postgres 9.3.9。

我需要知道此操作是否会导致表重写（锁定表），因为我的表很大并且数据库处于活动状态。

我在9.2发行说明中发现了这一点：

增加varchar或varbit列的长度限制，或完全删除该限制，不再需要重写表。 同样，提高数字列的允许精度，或将列从约束数字更改为无约束数字，不再需要重写表。 在涉及间隔，时间戳和时间戳类型的类似情况下，也避免使用表重写。

听起来很有希望，但实际上并未详细说明“类似情况”可能是什么。

如果此操作会锁定该表我会很感激了如何解决这个在实时数据库在不中断服务的建议。

Answer 1

首先，您似乎在混淆锁和表重写。 发行说明中的​​说明涉及表重写 - 始终对表进行ACCESS EXCLUSIVE锁定 。 但是，这里还有许多其他操作也需要加锁。

您将需要：

ALTER TABLE tbl ALTER ts_col TYPE timestamptz;

除非您要在转换中设置特定的时区，否则不要设置会话的当前时区：

ALTER TABLE tbl ALTER ts_col TYPE timestamptz USING ts_col AT TIME ZONE 'Europe/London';

在这种情况下，请确保使用时区名称 ， 而不是简单的偏移量或缩写。 细节：

• 具有相同属性的时区名称应用于时间戳时会产生不同的结果
• 在Rails和PostgreSQL中完全忽略时区

文档：

ALTER TABLE更改现有表的定义。 下面介绍了几个子窗体。 请注意，每个子窗体所需的锁定级别可能有所不同。 除非明确指出，否则将保留ACCESS EXCLUSIVE锁。

ALTER column_name TYPE data_type具有这种ACCESS EXCLUSIVE锁定 。 虽然timestamp和timestamptz的内部存储格式相同，但是内部值通常通过转换来更改（取决于会话的时区设置！）。 Postgres必须为表中的每一行编写一个新版本，因此也需要重写表 。 由于该操作使用了ACCESS EXCLUSIVE锁，因此无需保留旧的行版本，并且在转换后将看不到任何无效的元组。

SQL Fiddle演示了时区设置在转换中的作用。 我还添加了一个例子转换varchar ，以text ， 不需要一个表重写-除非你移动到更短的长度修正。
_{请注意我如何将输出转换为text （ ts_col::text ），以防止sqlfiddle中的JDBC层添加更多（通常是不希望的！）表示魔术。}

在您的事务开始之后，尝试访问该表的并发事务将等待，直到该事务完成。

您可以尝试通过在后台准备新表，删除旧表并重命名新表来缩短锁定时间，但这将导致并发事务失败，并显示以下错误：

错误：无法打开OID为123456的关系

细节：

• 在大表中填充新列的最佳方法？

timestamp / timestamptz “类似案例”

与varchar或numeric timestamp ， time和interval类型也可以使用修饰符 。 例如，默认情况下， timestamp(0)默认最多存储6位小数秒，但是您可以修改： timestamp(0)不存储小数秒。

从varchar(10) -> varchar(20)不需要表重写，因为源类型中的值也保证也适合目标类型（二进制兼容）。

对于timestamp (0) -> timestamp或timestamptz(3) -> timestamptz(5) 。 这就是本手册在发行说明中引用的段落中所指的内容：

在涉及interval ， timestamp和timestamptz类型的类似情况下，也避免使用表重写。