Windows下恢复PostgreSQL备份报TimeZone值localtime无效如何解决

问题根因 #

'localtime' 是PostgreSQL在类Unix（Linux/macOS等）平台专属的时区别名，依赖Unix系统的/etc/localtime时区文件机制，Windows平台的PostgreSQL无论哪个版本都不会识别这个时区值。因此更换9.3/9.4/14等不同版本的PostgreSQL for Windows都会复现报错，问题和数据库版本无关，属于跨平台兼容问题。
报错触发逻辑是备份中的函数定义硬编码了SET "TimeZone" TO 'localtime'语句，恢复到Windows环境时执行该语句直接触发参数合法性校验失败。

解决方法 #

方案1：预处理备份文件（最稳妥，推荐） #

不需要调整数据库配置，直接修复备份中的硬编码兼容问题：

• 如果备份是pg_dump生成的自定义压缩格式（后缀通常为.dump/.backup，无法直接用文本编辑器打开），先执行命令将备份转成可编辑的纯文本SQL格式：

  pg_restore -f converted_backup.sql 你的备份文件实际路径
  

  如果备份本身就是.sql后缀的纯文本格式，直接跳过这一步。
• 用任意文本编辑器打开转换后的SQL文件，执行全局精确替换：

  查找内容：SET "TimeZone" TO 'localtime'
  替换为：SET "TimeZone" TO LOCAL
  替换为LOCAL是SQL标准语法，全平台兼容，语义和原语句的'localtime'完全一致，都是调用当前会话的默认系统时区，不会改变原有函数的业务逻辑。如果需要固定时区，也可以替换为Windows下PostgreSQL支持的具体时区值，例如东八区可替换为'Asia/Shanghai'。

• 替换完成后保存文件，执行命令完成恢复：

  psql -d 目标库名 -U 你的数据库用户名 -f converted_backup.sql
  

方案2：恢复后批量修正函数定义（适合不想修改原备份的场景） #

如果不想改动原始备份文件，可以先完成核心数据恢复再统一修正问题：

• 执行恢复命令时添加--set ON_ERROR_STOP=0参数，让恢复流程跳过报错的函数创建步骤，先把表结构、数据、索引等核心内容恢复完成。
• 恢复完成后连接到目标库，执行以下SQL查询所有带错误时区配置的函数：

  SELECT n.nspname AS schema_name, p.proname AS function_name
  FROM pg_proc p
  JOIN pg_namespace n ON p.pronamespace = n.oid
  WHERE pg_get_functiondef(p.oid) LIKE '%SET "TimeZone" TO ''localtime''%';
  

• 对查询到的所有函数，逐个编辑函数定义，将'localtime'替换为LOCAL或者业务需要的合法时区值即可。

避坑提示 #

• 无需反复重装不同版本的PostgreSQL for Windows，所有官方发布的Windows版本PostgreSQL都不识别'localtime'时区别名，更换版本无法解决问题。
• 不要尝试通过修改postgresql.conf中的默认timezone参数绕开报错，报错触发原因是函数定义内硬编码了SET语句强制设置时区，和数据库全局默认时区配置无关。

内容的提问来源于stack exchange，提问作者scottctr