企业官网建设流程全解析

简介：postgresql-9.1.3-1-windows-x64压缩包是面向64位Windows平台的开源关系型数据库PostgreSQL 9.1.3稳定版安装资源，主要服务需要在Windows环境搭建或学习数据库的开发者、运维人员与IT学习者。压缩包仅2个文件，核心为exe安装程序，另附一份htm格式说明文档，整体约48.18MB；说明文档详细列出安装步骤、系统需求与许可协议，方便首次使用者按图索骥完成部署。该版本具备MVCC并发控制、全文搜索、窗口函数、PL/pgSQL存储过程语言等能力，支持异步复制与ACID事务，在高并发读写下仍能保证数据一致性与完整性；窗口函数可简化累计、排名等跨行计算，全文搜索便于文本检索，异步复制则可用于搭建只读副本，支撑负载均衡或灾备场景。借助说明文档还能学习数据目录配置、端口调整、连接参数设置及超级用户创建，并在安装后通过pgAdmin等工具执行建表、导入导出、备份恢复，覆盖日常运维关键环节；文档也会提醒硬件资源要求、端口开放策略与强密码设置等注意事项，帮助规避安装失败和安全遗漏。目前已有796人学习下载；该版本虽然发布较早，但核心机制成熟稳定，适合从入门到进阶的数据库用户在Windows 64位环境中复现老系统部署或开展学习实验。

1. postgresql-9.1.3-1-windows-x64：这个老版本为什么还有人在找

还在搜 postgresql-9.1.3-1-windows-x64 这个安装包的人，大概率不是图新鲜，而是手上有台老 Windows 服务器、一套跑了好几年的业务系统，或者一个只能装 9.1 的受限环境。这个版本是 2012 年初的补丁版，生命周期早已结束，可直到今天，依然有从业者在纠结 postgresql 下载哪个版本、能不能继续用。我的观点一向是：业务没坏就别乱动，但你必须先把它的安装、配置和迁出路径摸透。这篇文章讲的就是这条路：让 9.1.3 在 Windows x64 上稳定跑起来，再安全地把数据带出来。

2. 安装前准备：装之前必须做对的四件事

老版本安装最怕的不是版本老，而是准备工作没做透。很多人双击安装包就开始点下一步，结果装到一半回滚，或者装完服务起不来，最后只能骂骂咧咧地卸载重来。下面四项检查，每一项都能省掉后面至少一小时的排查时间。

2.1 安装包命名的信息量：9.1.3 和末尾的 -1 分别指什么

安装包文件名里有两段信息：9.1.3 是 PostgreSQL 的版本号，9 指大版本，1 指特性版本，3 指补丁版本；末尾的 -1 是 Windows 安装器自身的构建序号，和数据库版本没有关系。排查问题时不需要去纠结 -1 代表什么，只需要确认一件事：你拿到的确实是 9.1.x 分支的 x64 安装包。

选择哪个 PostgreSQL 版本，核心判断依据是你的业务需求。9.1 发布于 2011 年，9.1.3 作为补丁版发布于 2012 年，它的特性停留在那个时代：没有 JSONB、没有分区表原生支持、没有并行查询、没有逻辑复制。如果你的业务只用了简单的表、索引、视图、存储过程和触发器，9.1 完全够用；如果应用方要求新特性，那就别在老版本上硬撑，直接规划迁移。

还有一点值得注意：9.1 的 Windows 安装器在 Server 2008 R2 和 Windows 7 x64 上表现最稳定，在 Windows 10/11 上也能装，但可能出现兼容性提示。新系统上装老版本不是不行，而是你得接受它偶尔闹脾气。

2.2 Windows x64 兼容性：哪些系统能跑、哪些不建议硬装

这个安装包是 x64 版本，意味着 64 位系统是前提。Windows 7 x64、Windows Server 2008 R2 及之后的 64 位系统都能安装，但我的建议是：生产环境优先考虑 Windows Server，驱动和服务权限更可控。Windows 10/11 的桌面系统也能运行，适合本地开发测试，不适合作为线上数据库服务器。

32 位和 64 位的坑不在服务端，而在客户端。如果你的业务程序是 32 位应用，通过 TCP 方式连接 64 位 PostgreSQL 服务端没有问题，因为 libpq 走的是网络协议；但如果你的程序用 ODBC 连接，32 位应用必须安装 32 位版本的 PostgreSQL ODBC 驱动，和数据库服务端是 64 位无关。这是最容易搞混的点。

系统内存方面，9.1 在 Windows 上的共享内存实现决定了它不像 Linux 那样能轻松吃到几十 GB 内存。物理内存 8GB 以下的机器，9.1 跑得很轻松；内存越大，越要小心 shared_buffers 的取值，这会在第四章详细讲。

2.3 VC++ 运行库检查：9.1 依赖的老运行库经常缺席

老版本 Windows 安装包几乎都依赖对应版本的 VC++ 运行库，9.1 也不例外。常见报错是双击安装包或启动服务时提示"无法启动此程序，因为计算机中丢失 MSVCR90.dll"。很多人在新机器上装完最新的 VC++ 2015-2022 运行库，以为万事大吉，实际上 9.1 需要的是那个年代的 VC2008 运行库，二者互不替代。

检查方法是打开"程序和功能"，看有没有安装对应版本的 Visual C++ Redistributable。如果你不确定缺不缺，可以先试试启动安装程序，报错再补装；也可以直接查看 C:\Windows\System32 下有没有 msvcr90.dll 文件。

顺带提醒：有些精简版系统会把这些运行库删掉，装数据库之前先补运行库是通用习惯，别等到起服务时才一脸懵。

2.4 目录规划：安装目录和数据目录必须分开

9.1 安装器默认把数据库数据放在 C:\Program Files\PostgreSQL\9.1\data 下，这个位置很尴尬。Program Files 目录带 UAC 权限保护，数据库进程写数据时可能被拦，而且系统盘空间有限，数据库日志和 WAL 文件增长起来很快。

我一般会在数据盘单独建一个目录，比如 D:\pgdata\9.1。安装时把数据目录指到这个位置。如果已经按默认安装完，也不要慌，可以用 initdb 重新初始化一个新数据目录，再把服务注册到新目录上，这个流程第三章会给出完整命令。

路径选择上还有两个细节：目录路径尽量不要带中文，虽然 PostgreSQL 支持，但某些第三方备份工具和脚本会因编码问题翻车；目录路径不要带空格，比如避免 "D:\My Data\pg"，因为系统服务和命令行工具解析带空格的路径时容易出错。

3. 安装与初始化：从安装包到能连库的最小路径

这一章解决核心问题：怎么把这个安装包变成一台能连、能建表、能跑业务的数据库。两条路都给你：图形安装器适合单台机器，initdb 加 pg_ctl register 的组合适合需要精确控制的场景。

3.1 交互式安装的完整走查：每一步该选什么

双击安装包后，安装器会引导你完成配置。有几个界面需要特别留意。

第一是安装目录，默认是 C:\Program Files\PostgreSQL\9.1，建议保持默认即可，程序文件放在系统盘问题不大，关键是数据目录要改到独立位置。第二是数据目录，安装器会让你选择数据库文件的存放位置，这里务必指向你准备好的数据盘目录，比如 D:\pgdata\9.1。第三是超级用户密码，postgres 用户的密码要设置得复杂一些，因为这是数据库的最高权限账号，同时把密码记到密码管理工具里，别指望自己能记住。

端口默认 5432，如果本机已经被其他实例占用，改成 5433 或 5434 都可以，但要确保防火墙和连接串里同步修改。Locale 选择是整场安装里最关键的一步，安装器默认会跟随系统区域，在简体中文 Windows 上会得到 GBK 编码的数据库，后患无穷。我的建议是选择与 UTF8 对应的选项，或者在安装完成后用 initdb 重建数据目录。

安装完成后，安装器会自动注册 Windows 服务并启动数据库。看到"成功安装"不代表一切正常，一定要按 3.4 节的验证步骤确认一遍。

3.2 用 initdb 手动建库：适合服务器环境的初始化

图形安装器偶尔会在权限和编码上自作主张，所以我更推荐在服务器上用 initdb 手动初始化数据目录，尤其是当你需要完全掌控数据目录位置和编码时。命令如下：

"C:\Program Files\PostgreSQL\9.1\bin\initdb.exe" -D "D:\pgdata\9.1" -E UTF8 --locale=C -U postgres -A md5 --pwfile="C:\temp\pgpass.txt"

逻辑说明：initdb 的作用是初始化一个空的数据目录，生成 postgresql.conf、pg_hba.conf、基础系统数据库等必备文件。-D 指定数据目录位置，目录必须为空或不存在；-E UTF8 指定数据库默认编码为 UTF8；--locale=C 指定使用 C 语言环境，避免中文 Windows 默认 locale 带来的排序和编码问题；-U postgres 指定超级用户名为 postgres；-A md5 指定默认认证方式为 md5 密码认证；--pwfile 从文件读取密码，避免密码出现在命令行历史中。

参数说明：如果你确定业务不需要 UTF8，也可以把 -E 改成你需要的编码，但大多数现代应用都以 UTF8 为佳。-A 参数建议必选 md5，不要用 trust，否则本地任何用户都能免密登录。-U postgres 可以改成其他用户名，但后续连接工具默认都识别 postgres，非必要不要改。

执行成功后，数据目录下会出现 postgresql.conf 和 pg_hba.conf 两个文件，后续配置都改这里。如果 initdb 报错，先检查数据目录是否为空、当前 Windows 用户是否有该目录的写权限。

3.3 pg_ctl register 注册 Windows 服务

initdb 只是生成了数据目录，还需要把数据库注册成 Windows 服务，让它开机自启、随系统管理。命令如下：

"C:\Program Files\PostgreSQL\9.1\bin\pg_ctl.exe" register -N postgresql-x64-9.1 -D "D:\pgdata\9.1" -U "NT AUTHORITY\NetworkService" -S auto

逻辑说明：pg_ctl 是 PostgreSQL 的服务控制工具，register 子命令用于注册 Windows 服务。-N 指定服务名称，我习惯用 postgresql-x64-9.1，和图形安装器生成的服务名保持一致，方便后续识别；-D 指定数据目录，必须和 initdb 时一致；-U 指定服务运行的系统账号，这里用 NetworkService，它是 Windows 内置账号，权限受限但足够 PostgreSQL 运行，安全性更好；-S auto 表示服务随系统自动启动。

参数说明：如果不加 -U，默认以本地系统账号运行，权限过大且某些网络访问行为受限。用 NetworkService 时，必须确认该账号对数据目录 D:\pgdata\9.1 有完全控制权限，否则服务启动时无法读写数据文件。设置目录权限的方法是：右键数据目录，在安全选项卡里添加 NetworkService 账号并赋予完全控制。

服务注册完成后，可以通过net start postgresql-x64-9.1启动服务，net stop postgresql-x64-9.1停止服务。也可以进入服务管理界面查看服务状态，确认启动类型是否为"自动"。

3.4 安装后的三分钟验证：别急着交差

服务启动之后，先用最简单的命令确认数据库真的能用。打开命令提示符，执行：

"C:\Program Files\PostgreSQL\9.1\bin\psql.exe" -h localhost -p 5432 -U postgres -d postgres -c "select version();"

这条命令用 psql 连接本机 5432 端口的 postgres 数据库，执行版本查询。如果能看到 PostgreSQL 9.1.3 的版本信息，说明服务端启动正常、认证配置正确、客户端连接链路通畅。

接下来检查端口监听状态：

netstat -ano | findstr 5432

正常应该看到 TCP 0.0.0.0:5432 或 127.0.0.1:5432 的监听记录。如果只看到 127.0.0.1，说明 listen_addresses 还没放开，远程连接不了，这个在第四章处理。

最后测试建表和简单查询：

psql -h localhost -U postgres -d postgres -c "create table test_check(id int); drop table test_check;"

逻辑说明：建表再删表，确认数据目录可写、事务可提交。如果这步报错，大概率是数据目录权限问题，回到 3.3 节检查 NetworkService 账号权限。三分钟验证做完，这台数据库才算是真正能干活了。

4. 让 9.1 跑顺：配置文件的真实调参

这一章聚焦 9.1 在 Windows x64 上最常见的配置调整。配置文件只有两个：postgresql.conf 管性能和行为，pg_hba.conf 管谁能连。改之前先备份原文件，改完之后用 reload 方式加载，尽量不重启服务。

4.1 postgresql.conf 必调参数：从默认配置到能扛业务

9.1 的默认配置非常保守，只能保证服务能启动，扛不住真实业务。打开 D:\pgdata\9.1\postgresql.conf，找到以下几组参数，按你的机器配置调整。

shared_buffers = 256MB work_mem = 16MB maintenance_work_mem = 64MB checkpoint_segments = 32 checkpoint_completion_target = 0.9 fsync = on

逻辑说明：shared_buffers 是 PostgreSQL 的共享缓存池，9.1 在 Windows 上受共享内存实现限制，不宜设置过大，物理内存 8GB 的机器建议 256MB 到 1GB 之间，超过物理内存四分之一容易导致启动失败。work_mem 是单次排序和哈希操作可用的内存，默认只有 1MB，复杂查询很容易落盘，调到 16MB 是安全起点，但要注意这个值是每个排序操作独立计算的，并发高时总内存消耗会放大。maintenance_work_mem 用于建索引、VACUUM 等维护操作，64MB 是合理起步值。checkpoint_segments 控制 WAL 日志在触发检查点前可累积的段数，9.1 默认只有 3，相当于 48MB，写入频繁时会导致检查点过于频繁、磁盘 IO 飙升，调到 32 能明显缓解。checkpoint_completion_target 表示检查点要在多长时间窗口内完成，0.9 能更平滑地分散写入压力。fsync 保持 on，这是数据安全底线，千万别关。

参数说明：9.1 没有 max_wal_size 和 min_wal_size 这两个参数，它们是后面大版本才引入的，照着新版本文档调会直接报参数不存在。如果你需要做基于 WAL 的持续归档备份，还需要把 wal_level 从默认的 minimal 改为 archive，同时配置 archive_mode 和 archive_command，注意这个调整需要重启数据库才能生效。

4.2 pg_hba.conf：认证规则的最小改动

pg_hba.conf 控制客户端连接认证方式。9.1 安装器生成的默认配置通常只允许本机 127.0.0.1 和 ::1 连接，本地连接认证方式可能是 trust 或 md5。你需要按业务需要做两件事：放开局域网访问、收紧本地认证。

# 原默认配置 host all all 127.0.0.1/32 md5 host all all ::1/128 md5 # 新增局域网网段访问 host all all 192.168.1.0/24 md5

逻辑说明：pg_hba.conf 从上到下逐行匹配，连接请求只要命中第一行匹配规则就不再往下看，所以常用规则放在前面。host 表示 TCP 连接，all 表示所有数据库，后面的 all 表示所有用户，192.168.1.0/24 是允许访问的网段，md5 表示密码认证。

参数说明：如果你只想让某一个 IP 连，把网段写成具体的 IP 加 /32，比如 192.168.1.100/32。如果局域网环境可信，可以用 trust 免密，但生产环境强烈不建议。改完 pg_hba.conf 不需要重启，只执行 reload 即可：

"C:\Program Files\PostgreSQL\9.1\bin\pg_ctl.exe" reload -D "D:\pgdata\9.1"

同时记得把 postgresql.conf 里的 listen_addresses 从默认的 localhost 改成 '*'，否则即使 pg_hba.conf 放开了网段，服务端也不会监听对外网卡，这个改动需要重启数据库生效。

4.3 Windows 下的日志与编码：三个容易被忽略的运维习惯

9.1 的日志默认写在数据目录下的 pg_log 文件夹里，文件名形如 postgresql-2012-03-12_000000.log，按天和序号滚动。出问题时先看这个目录，日志里没有报错，再看 Windows 事件查看器的应用程序日志，这个排查顺序能覆盖大部分启动失败场景。

编码方面，如果你在 initdb 时用了 -E UTF8 --locale=C，那数据库内部编码就是 UTF8。但 Windows 客户端的默认 client_encoding 可能仍然是 GBK，导致写入的数据乱码。解决办法是在连接串里显式指定编码，或者在 psql 里执行set client_encoding to 'UTF8';。应用程序连接 PostgreSQL 时，JDBC 连接串可以加 characterEncoding=UTF-8，ODBC 则在连接配置里选择 Unicode 驱动。

时区也是一个容易踩的地方。9.1 默认 timezone 跟随操作系统时区，如果你的服务器设在虚拟机上且时区混乱，数据库返回的时间会跟着错。建议在 postgresql.conf 里显式设置 timezone，比如 timezone = 'Asia/Shanghai'，统一到一个固定值，避免依赖系统设置。

4.4 9.1 与现代版本的行为差异：调试时别拿新思维套老版本

9.1 和现在的新版本在语法层面有不少差异，调试老系统时最容易犯的错，就是拿新版本的特性去套 9.1。例如 9.1 不支持CREATE INDEX IF NOT EXISTS，也不支持ALTER TABLE ... DROP COLUMN IF EXISTS的完整语义，从新版本迁移过来的脚本，在 9.1 上执行会直接语法报错。

认证方式的差异同样关键。9.1 的密码认证只认识 md5 和 trust，不认识新版本默认的 scram-sha-256。如果你从高版本复制一份 pg_hba.conf 到 9.1，服务端会直接报 unsupported authentication method，导致所有连接失败。反过来，高版本客户端连接 9.1 时，如果客户端强制要求 SCRAM 认证，也会握手失败。处理办法是统一让客户端使用 md5 兼容模式，或者在连接串里指定认证方式。

权限模型也有差异。9.1 的默认权限控制比新版本宽松，public schema 上对 public 角色默认有 CREATE 权限，任何能连上来的用户都能在 public schema 里建表。安全要求高的场景，需要手动REVOKE CREATE ON SCHEMA public FROM PUBLIC;。这个细节在新版本里已经默认收紧，所以老版本接手后一定要检查一遍权限。

5. 常见问题排查：9.1.x 在 Windows x64 上最容易翻车的五个点

老版本在 Windows 上跑的痛，基本都是这几个问题。每一条都按现象、原因、解决三步展开，你可以直接按症状对号入座。

5.1 服务启动即停止，日志里却什么都没有

现象：服务管理器里点击启动，状态从"正在启动"弹回"已停止"，去数据目录的 pg_log 文件夹看，日志文件是空的，或者只有几行初始化信息。Windows 事件查看器里也看不到具体报错。

原因：八成的概率是数据目录权限不对。Windows 服务以 NetworkService 账号运行，而这个账号对数据目录 D:\pgdata\9.1 没有写权限，导致 postgres 进程初始化共享内存或创建日志文件失败。还有两成概率是 shared_buffers 设置过大、超出了 Windows 分配给该服务的资源限额。

解决：先检查数据目录的 ACL 权限，给 NetworkService 账号添加完全控制权限，然后重启服务。如果权限没问题，把 postgresql.conf 里 shared_buffers 改成 128MB 再试。两者都不行，用命令pg_ctl -D D:\pgdata\9.1 start前台启动，报错信息会直接打到终端，比翻日志直观得多。

5.2 远程连接超时，netstat 看到 5432 只监听 127.0.0.1

现象：本机 psql 连接正常，局域网里其他机器 telnet 数据库服务器 IP 的 5432 端口不通，netstat 发现监听地址是 127.0.0.1:5432 而不是 0.0.0.0:5432。

原因：postgresql.conf 里的 listen_addresses 默认值是 localhost，只监听了回环地址，对外网卡完全没有监听。另一个原因是 Windows 防火墙没有放行 5432 端口，连接请求到了服务器网卡，但被防火墙拦截了。

解决：把 postgresql.conf 里的 listen_addresses 改成 '*'，重启数据库。然后确认防火墙入站规则里有 TCP 5432 的放行规则。老版本安装器偶尔会创建防火墙规则，但也有不创建的情况，手动添加最稳：防火墙高级设置里新建入站规则，端口选 TCP 5432，允许连接。改完检查 netstat，确认监听地址变成 0.0.0.0:5432 再测试远程连接。

5.3 中文乱码：locale 选错，建库之后一路乱到今天

现象：数据库连上后，查出来的中文是乱码，写入中文报"character with byte sequence 0x... in encoding GBK has no equivalent in UTF8"，或者反过来，UTF8 中文在 GBK 客户端下变成问号。

原因：安装时 locale 跟随了中文 Windows 系统默认值，initdb 初始化出来的数据库编码是 GBK，而客户端连接串用的是 UTF8，两边对不上。这个问题的根源在初始化阶段选错了编码，后期只能靠转换补救。

解决：已经跑起来的库，先确认服务端编码和客户端编码，分别执行show server_encoding;和show client_encoding;。服务端如果是 GBK，客户端连上后执行set client_encoding to 'GBK';能缓解乱码，但这不是长久之计。根本解法是按第三章的 initdb 命令重建数据目录，用 -E UTF8 --locale=C 初始化，然后通过逻辑导出导入把数据挪过去。记住这个教训：任何新装实例的数据目录，初始化时就必须把 UTF8 定死。

5.4 pg_hba.conf 报 unsupported authentication method

现象：修改 pg_hba.conf 后 reload，所有客户端连接都失败，数据库日志里出现 unsupported authentication method 的报错。

原因：pg_hba.conf 里写了 9.1 不认识的认证方式。最常见的操作是从新版本数据库复制配置过来，把服务器新版本默认的 scram-sha-256 带到了 9.1。9.1 只认识 trust、md5、password、reject 这些老认证方式，遇到 scram 直接拒绝。

解决：打开 pg_hba.conf，把所有认证方式统一改成 md5，保存后 reload。同时检查客户端连接配置，高版本客户端默认可能请求 SCRAM，配合服务端 md5 时需要客户端允许使用 md5 认证。最稳妥的办法是让客户端 libpq 版本不要过高，或者明确在连接参数里指定认证方式。排查这个问题时，可以先看一眼日志里具体是哪一行规则报错，修正后逐个测试。

5.5 pg_dump 版本不匹配，备份刚开始就翻车

现象：打算把 9.1 数据导出来迁移，执行 pg_dump 时直接报错，大致意思是 server version is 9.1.3, but pg_dump version is 14.x，不让你继续备份。

原因：系统 PATH 环境变量里指向的是新版本 PostgreSQL 的 bin 目录，你敲 pg_dump 时实际调用的是高版本的 pg_dump。PostgreSQL 为了保证备份一致性，不允许用差异过大的客户端版本连接服务端做备份。

解决：备份时明确使用 9.1 安装目录下的 pg_dump 可执行文件：

"C:\Program Files\PostgreSQL\9.1\bin\pg_dump.exe" -h localhost -p 5432 -U postgres -F c -b -v -f "D:\backup\app_9_1.dump" appdb

逻辑说明：-F c 表示自定义压缩格式，便于之后用 pg_restore 选择性地恢复；-b 表示包含大对象；-v 输出详细日志；-f 指定备份文件路径；最后一个参数 appdb 是要备份的数据库名。执行前先用pg_dump.exe --version确认版本号是 9.1.3，再执行备份。如果你希望恢复时更方便，可以不加 -F c，直接输出纯 SQL 格式，但自定义格式更灵活，我推荐保持 -F c。

6. 进阶用法：从 9.1 平滑迁到新版本的工具链

老版本总有一天要交班，迁移是最有价值的高级操作。我的思路是：逻辑备份为中间媒介，目标版本用新库接住，全程不做 in-place 升级，降低风险。

6.1 迁移前先做一次家底体检

迁移前必须知道这个库里有什么。执行下面这条 SQL，把数据库里的对象摸一遍：

select count(*) as total_tables from information_schema.tables where table_schema not in ('pg_catalog','information_schema');

这条命令统计业务 schema 下的表数量。再看有没有大对象和扩展：

select count(*) from pg_largeobject_metadata; select extname from pg_extension;

如果发现大量大对象，备份时务必带 -b 参数；如果扩展列表里有非内置扩展，目标库也要安装对应版本。这一步决定你后面备份命令怎么写。

6.2 用 9.1 原配 pg_dump 做逻辑备份

迁移备份的命令和第五章的日常备份一样，必须用 9.1 自带的 pg_dump：

"C:\Program Files\PostgreSQL\9.1\bin\pg_dump.exe" -h localhost -U postgres -F c -b -v -f "D:\backup\app_9_1.dump" appdb

备份完成后，先检查文件大小是否正确，再用 pg_restore 的 --list 参数预览内容，确认里面包含了预期中的表和索引。

6.3 用新版本 psql 恢复与校验

在目标新版本实例上创建同名数据库，然后用 pg_restore 恢复：

"C:\Program Files\PostgreSQL\16\bin\psql.exe" -h localhost -U postgres -c "create database appdb;" "C:\Program Files\PostgreSQL\16\bin\pg_restore.exe" -h localhost -U postgres -d appdb -v "D:\backup\app_9_1.dump"

恢复完成后，对比表行数和关键数据。先在老库执行：

"C:\Program Files\PostgreSQL\9.1\bin\psql.exe" -h localhost -U postgres -d appdb -c "select count(*) from main_table;"

再到新库执行同样语句，数字一致才算迁移成功。迁移期间老库不要停，确认新库跑通了再切换连接串。我坚持的习惯是：老库保留至少一周，新库跑几天再决定是否清理老环境，这个习惯帮我躲过多次迁移返工。希望帮到你。

本文还有配套的精品资源，点击获取