
简介面向64位Windows环境的PostgreSQL 9.1.3安装压缩包适合需要在传统Windows服务器或老旧生产环境中部署开源关系型数据库的运维人员、DBA及数据库初学者。该版本虽是2012年发布的稳定版但已具备MVCC并发控制、全文检索、窗口函数、存储过程、异步复制等核心能力可用于构建中小型业务系统或学习数据库原理。压缩包共2个文件包含一个exe安装程序和一个htm说明文档整体约48.18MB说明文档涵盖系统需求与安装引导。已有796人学习下载可直接作为Windows x64环境下的部署参考。通过实际安装配置读者能掌握数据目录设置、端口与连接参数调整、超级用户创建等基础操作并可借助pgAdmin进行日常管理为后续使用PL/pgSQL或处理复杂查询打下基础。1. 一个 2013 年的安装包还在流传postgresql-9.1.3-1-windows-x64 到底是什么很多人在查“postgresql下载哪个版本”的时候会被老教程带到这个文件名上postgresql-9.1.3-1-windows-x64。双击安装完要么服务起不来要么 psql 连不上最后跑到群聊里问“这个版本是不是坏了”。它不是坏了而是太老了。这是 PostgreSQL 9.1 系列的第三个补丁版由 EnterpriseDB 打包发布的原生 64 位 Windows 安装程序发布于 2013 年前后。它的价值不在新而在老旧系统维护、老项目迁移前做基线验证、以及给历史数据找一个能带走的出口。这篇笔记写给要碰老实例的人和替旧系统擦玻璃的运维新项目请直接看 16 或 17别碰 9.1。2. 拆解安装包9.1.3-1 在 Windows x64 上的真实身份与前置条件安装包的命名不是乱来的。9.1.3 是版本号-1 是 EnterpriseDBEDB的打包序号windows-x64 说明这是一个原生 64 位构建不是 32 位程序在兼容模式下跑。搞清楚这层之后后续所有安装和排错才会有方向。2.1 文件名与版本号9.1.3 到底处于什么位置PostgreSQL 的版本规则是“主版本.次版本.补丁版本”。9.1 是主版本9.1.3 表示在 9.1 主版本上的第 3 个补丁发布。9.1 主版本上线于 2011 年带来了扩展机制EXTENSION、可写公共表表达式Writable CTE和同步复制这些都是后来很多运维习惯的基础。9.1.3 是 9.1 中期的一个补丁版主要修掉了一批基础 bug其中不少和 Windows 平台的数据目录锁、内存分配有关。后面那个 -1 是 EDB 打包号表示这个安装包是 EDB 对这个上游版本做的第 1 次 Windows 打包。EDB 的安装包会把 PostgreSQL 主程序、pgAdmin 客户端、Stack Builder 组件选择器一起塞进来默认安装路径是 “C:\Program Files\PostgreSQL\9.1”bin、lib、data、pgAdmin III 都在这个大目录里。之所以强调 64 位身份是因为 9.1 时代还同时发布过 32 位构建两个版本的数据目录不能互换使用pg_ctl 读取 pid 文件的方式也不一样。验证装进系统里的是不是 x64 版本可以直接查 postgres.exe 的重定向头也可以在 PowerShell 里看版本信息Get-ChildItem C:\Program Files\PostgreSQL\9.1\bin\postgres.exe | Select-Object FullName, {NameFileVer;Expression{$_.VersionInfo.FileVersion}}这段命令读取 postgres.exe 的文件版本号能确认安装包是否真的落到了 x64 的程序目录。如果这个路径不存在或者文件版本显示的是 9.1.3 但你安装时选了 32 位组件后面做内存配置和共享缓冲区调整的时候上限和参数行为都会不一样。2.2 运行库前置条件先装 VC x64 运行库别急着双击9.1.3-1 的 EDB 安装器是基于 InstallAnywhere 打包的它会在安装过程中注册 Windows 服务和写入注册表项对 C 运行库比较敏感。很多人在新虚拟机里直接双击安装包进度条走到一半整体回滚弹出一个“错误 1603”。这个错误我在实际维护里见过太多次绝大多数是因为缺少 x64 的 VC 运行库。9.1 时代静态链接的运行库版本主要是 Visual C 2013所以安装前先检查两个文件是否存在vcruntime140.dll 对应 2015-2022 运行库msvcr120.dll 对应 2013 运行库。一条 PowerShell 命令可以同时看Get-ChildItem C:\Windows\System32\vcruntime140.dll, C:\Windows\System32\msvcr120.dll -ErrorAction SilentlyContinue | Select-Object Name, {NameVer;Expression{$_.VersionInfo.FileVersion}}有输出就说明对应的 x64 运行库已经在系统里没输出就去微软官方下载对应版本的 redistributable。装完 2013 再装 PG没有先装运行库就反复重装 PG 或者把 32 位运行库当成 x64 来用安装器照样报 1603。还有一点容易被忽略64 位系统里 vcruntime140.dll 同时存在于 System32 和 SysWOW64前者给 64 位程序用后者给 32 位程序用。检查一定要看 System32 路径SysWOW64 里的那一个对 postgresql-9.1.3-1-windows-x64 不起作用。2.3 与新版对比9.1.3 和 16/17 该怎么选很多搜索“postgresql下载哪个版本”的人是先被某个教学视频带到这里的。9.1.3 和现在主流的 16、17 在安装体验、安全性和维护成本上差异非常大不能说哪个更好只能说哪个更合适对比项postgresql-9.1.3-1-windows-x64PostgreSQL 16/17发布年份2013 前后近两年生命周期早已停止维护仍在社区维护期安全补丁无持续更新安装器形态InstallAnywhere单文件 exe标准 NSIS 安装器流程更规范默认认证md5scram-sha-256数据目录结构PG_VERSION data 目录结构简单同上但新增大量并行 WAL 选项适合场景老实例复现、迁移源库、旧代码兼容新项目、生产环境只有两种情况值得装 9.1.3一是生产线上确实还跑着 9.1 的旧实例需要本机装一个同版本做对照测试二是某个老业务系统指定要用这个版本。如果只是学习 PostgreSQL 或者搭新环境直接上 16/17否则你会在认证插件、默认权限和二进制目录结构这些地方白白消耗大量时间。3. 从安装包到可用实例初始化、服务注册和连接验证“双击 exe 一直下一步”是能装完但装完服务起不来、psql 连不上的概率不低。根因多半出在安装器把数据目录默认放在 “C:\Program Files\PostgreSQL\9.1\data”Windows 的 UAC 和用户目录权限会在重启后拒绝 postgres 服务账户对数据目录的写操作。所以更靠谱的做法是安装器只装程序文件数据目录单独初始化到独立盘符上。3.1 安装向导里几个默认值要改掉交互式安装的第一步让选安装目录保持默认 “C:\Program Files\PostgreSQL\9.1” 就行但第二步数据目录建议直接改成 D:\pgdata。这一步的路径后面要写进服务注册命令和数据目录参数如果路径带空格或者中文字符注册服务和读取配置都会碰到额外的转义问题。接着是密码设置和端口号。9.1 的安装器会要求设置超级用户 postgres 的密码注意 9.1.3 的默认加密方式是 md5不是现在新版本里的 scrum-sha-256后面所有客户端配置都要以 md5 为基准。端口默认 5432如果机器上已经装了别的 PostgreSQL把端口改成 5433并记住这个端口连接验证全部要带 -p 参数。组件选择页面里Stack Builder 那个扩展组件工具可以取消勾选它通常需要联网下载额外组件对本地部署没有帮助。pgAdmin III 是 9.1 自带的管理客户端如果只是用 psql 操作不勾选也不影响服务端功能。3.2 手动初始化数据目录initdb 的最小命令安装器走完bin 目录下已经有了 initdb.exe 和 pg_ctl.exe。用 initdb 初始化独立数据目录这一步相当于把安装器和数据目录解耦后续升级和备份都更灵活。在管理员 CMD 或 PowerShell 里执行C:\Program Files\PostgreSQL\9.1\bin\initdb.exe -D D:\pgdata -U postgres -W -A md5 -E UTF8 --localeC这个命令里-D 指定数据目录为 D:\pgdata-U postgres 设置超级用户名称-W 会提示手动输入两次密码-A md5 把 pg_hba.conf 默认认证方式写成 md5-E UTF8 把默认字符集设为 UTF-8--localeC 强制使用 C 排序规则。-W 和 -A md5 要一起用否则 initdb 生成的 pg_hba.conf 里是 trust 认证服务能启动但客户端不需要密码就能进库这在生产环境里是很危险的。--localeC 这部分Windows 平台上如果选了 Chinese 相关排序规则某些老版本在 ORDER BY 中文时会出现和 Linux 端不一致的行为统一用 C 排序规则能减少这类环境差异。初始化结束后D:\pgdata 下会出现 PG_VERSION、postgresql.conf、pg_hba.conf 和 base 目录等文件。看到这些文件说明第一步成功。3.3 注册 Windows 服务pg_ctl register 与启动顺序初始化好数据目录之后用 pg_ctl 注册 Windows 服务而不是直接双击 postgres.exe。直接双击只会在当前终端里跑一个前台进程关掉窗口服务就没了重启机器也不会自动拉起来。C:\Program Files\PostgreSQL\9.1\bin\pg_ctl.exe register -N postgresql-9.1-x64 -D D:\pgdata -U postgres -P your_password -S auto net start postgresql-9.1-x64register 命令的作用是把 PostgreSQL 实例注册为 Windows 服务-N 服务名写 postgresql-9.1-x64-D 指定数据目录 D:\pgdata-U 和 -P 指定服务登录账户和密码。服务账户建议用 postgres它是安装器创建的低权限账户专门用来跑数据库服务避免用 Administrator 跑实例出问题时权限边界不清楚。-S auto 让服务随 Windows 自动启动。执行 net start 之后如果立即报“服务没有响应”先不要急着重装。打开事件查看器看 PostgreSQL 日志路径在 D:\pgdata\pg_log\postgresql-*.log80% 的情况是数据目录权限不对或者端口被占用。日志里如果有 “could not bind IPv4” 字样说明 5432 被别的进程吃掉了去配置里改端口。3.4 连接验证与防火墙放行服务起来之后第一件事不是连数据库而是在本机确认端口监听状态。CMD 里执行下面的命令netstat -ano | findstr 5432看到 LISTENING 状态和对应 PID说明服务在监听。如果 netstat 里完全没有 5432 的行有两种可能一是 postgresql.conf 里 listen_addresses 没生效二是服务其实没起来。前者修改 postgresql.conf 里的 listen_addresses本机连接写 localhost 即可不需要改成 *。端口正常后用 psql 做一次真实连接C:\Program Files\PostgreSQL\9.1\bin\psql.exe -h 127.0.0.1 -p 5432 -U postgres -d postgres -W-h 指定 127.0.0.1 是为了强制走 TCP 而不是本机 IPC这样可以顺便验证监听配置和密码认证是否生效。-W 会让 psql 交互式提示输入密码。如果等待远程客户端访问再放行 Windows 防火墙netsh advfirewall firewall add rule namePostgreSQL 9.1 5432 dirin actionallow protocolTCP localport5432dirin 表示放行入站流量actionallow 允许连接localport5432 限定端口避免把整个服务器的所有入站都放开。注意防火墙只放行端口不会帮你处理认证pg_hba.conf 里的 host 规则仍然会生效远程机器能不能登录取决于那一行是 md5 还是 trust。4. 老版本踩坑记录五条从安装到连接的血泪经验9.1.3 在 Windows 上的问题非常集中很多都不是偶发而是这个版本在特定环境下的必然结果。按“现象-原因-解决”的顺序整理五条基本覆盖从安装到使用的绝大多数翻车点。4.1 安装到一半回滚报“错误 1603”现象双击 postgresql-9.1.3-1-windows-x64.exe进度条走一大半后用安装日志显示“错误1603”整个安装流程回滚控制面板里也找不到残留。原因1603 是 Windows Installer 的通用错误在 9.1.3 上最常见的原因有三个按顺序排查缺少 x64 的 VC 运行库安装包注册服务或扩展名时失败安装程序没有以管理员权限运行Program Files 目录写入被拒安全软件在安装过程中扫描并锁定了即将写入的 exe 和 dll 文件。解决先确认系统里有 msvcr120.dll 和 vcruntime140.dll 的 x64 版本再右键安装包选择“以管理员身份运行”然后临时退出安全软件。还有一个隐蔽点9.1.3 安装器的解压临时目录默认在 %TEMP% 下如果 C 盘剩余空间不足 1GB安装器会在写临时文件时失败并回滚成 1603。先把 %TEMP% 的磁盘空间清出 2GB 再装很多老机器上的 1603 就是这么解决的。4.2 设置好的密码psql 偏偏认证失败现象安装或 initdb 时明明设置了 postgres 密码psql 连接却一直提示 password authentication failed密码反复输入都不对。原因第一种是 pg_hba.conf 里 host 行的认证方式还是 trust。9.1.3 安装器在部分交互流程下会生成 trust 规则psql 这时候根本不需要密码一旦你输入密码反而会因为“多余的密码”触发校验失败。第二种是密码中包含特殊字符比如 $、、引号在 initdb -W 交互输入或者命令行里被 CMD 转义实际写入 pg_hba 的密码和你以为的不一样。解决打开 D:\pgdata\pg_hba.conf确认这一段host all all 127.0.0.1/32 md5如果上面是 trust改成 md5 然后重载配置。特殊字符问题用 --pwfile 把密码写入临时文件再交给 initdb避免命令行转义echo Your$trongPss C:\temp\pgpw.txt C:\Program Files\PostgreSQL\9.1\bin\initdb.exe -D D:\pgdata -U postgres -A md5 --pwfileC:\temp\pgpw.txt -E UTF8 --localeC del C:\temp\pgpw.txt这里用 --pwfile 让 initdb 从文件读取密码密码文件用完立刻删除避免留在磁盘上。注意 CMD 里 echo 的 会创建文件但结尾会多一个空格如果密码末尾不能有空格用 PowerShell 的 Set-Content 更精确。重载配置可以用 pg_ctl reload -D D:\pgdata比重启服务影响小。4.3 pgAdmin 连不上psql 却一切正常现象psql 用 127.0.0.1 和 5432 能正常登录打开 pgAdmin 3 填了同样的主机、端口和用户连接时报 SSL 错误或者直接超时。原因9.1 的 pgAdmin 3 自带 libpq 的 SSL 默认行为和后来的 Windows 系统 SSL 配置有兼容问题尤其是当 pg_hba.conf 里没有显式关闭 SSL 时pgAdmin 会先尝试 SSL 加密握手而 9.1.3 的加密证书链在老系统上可能没有正确装载。另一个原因是 pgAdmin 里主机名填了 localhost在 Windows 上 localhost 解析到 IPv6 ::1而 postgresql.conf 里 listen_addresses 默认只监听了 127.0.0.1。解决在 pgAdmin 连接属性里把 SSL 选项明确设为 disable主机地址写 127.0.0.1 而不是 localhost。如果必须走 SSL就得去看服务端 postgresql.conf 里 ssl 是否打开以及是否配置了 server.crt 和 server.key。9.1.3 默认 ssloff这是老版本和现在 pgAdmin 之间最常见的错位点。换成 psql 做日常操作就没这些麻烦pgAdmin 只用来查表和看执行计划。4.4 重启服务器后服务一直停在“正在启动”最后报 1053现象Windows 服务管理器里 postgresql-9.1-x64 显示“正在启动”等几十秒后自动变回“已停止”事件日志里出现“服务没有及时响应启动或控制请求1053”。原因服务登录账户的密码在重启后失效或者数据目录 D:\pgdata 所在磁盘的权限没有给服务账户。9.1.3 注册服务时用 -U postgres -P 指定了密码一旦 Windows 账户策略强制该账户下次登录必须改密码服务就会起不来。另一个原因是 D:\pgdata 是在当前管理员账户下创建的目录 ACL 只给了这个管理员服务账户 postgres 没有读权限启动时读不到 PG_VERSION 直接失败。解决打开服务管理器双击 postgresql-9.1-x64 服务切到“登录”选项卡把登录身份改成“本地系统账户”重启服务先确认数据目录本身没有损坏。如果是权限问题用 icacls 给服务账户授予完全控制icacls D:\pgdata /grant postgres:(OI)(CI)F /T这个命令把 D:\pgdata 及其子目录和文件的完全控制权限显式授予 postgres 账户。注意 1053 的本质是服务超时有时杀毒软件扫描数据文件也会拖慢启动但权限和密码过期是最常见的两个根因先排查它们再去动杀毒配置。4.5 5432 端口被占用服务起来但连不上现象服务显示正在运行netstat -ano | findstr 5432 却输出另一个 PIDpsql 连接报 connection refused 或超时。原因机器上之前装过别的 PostgreSQL 版本老实例还占着 5432或者 nginx、其他中间件把 5432 当默认端口。9.1.3 安装器检测到端口冲突时往往会静默跳到 5433但手动注册服务时如果没注意配置就启动在 5432实际监听不到。解决先用 netstat 拿到占用进程的 PID再在任务管理器里确认进程名。如果确实是另一个实例不要 taskkill 乱杀避免影响别的业务直接把 9.1.3 的端口改成未被占用的值port 5433改完 D:\pgdata\postgresql.conf 后重启服务pg_ctl reload -D D:\pgdatareload 对端口修改不生效端口属于启动参数必须完全重启服务才能读到新值所以这里要执行 net stop postgresql-9.1-x64 然后 net start或者用 pg_ctl restart -D D:\pgdata。改端口之后所有客户端连接都必须带 -p 5433否则还是连不上。还有一个细节pg_hba.conf 里注释掉的行不影响端口但如果你在文件里写过 port 字段那只会被当作注释解析不会覆盖 postgresql.conf。5. 把老实例的数据安全带走pg_dump 备份与恢复验证9.1.3 不管跑得多顺它都是一个停止维护的老版本。真正要做的事情是把数据从这个黑匣子里完整带出来迁到新版或者至少留一个可恢复的备份。逻辑备份是这条路上最可靠的后悔药。5.1 逻辑备份的最小命令单库、全部库、角色单库备份用 pg_dumpcustom 格式是首选因为它带压缩、支持并行恢复还能用 pg_restore 选择性恢复单个表C:\Program Files\PostgreSQL\9.1\bin\pg_dump.exe -h 127.0.0.1 -p 5432 -U postgres -d mydb -F c -f D:\backup\mydb_913.dump -v-F c 表示 custom 格式-f 指定备份文件路径-v 打印每个对象的导出进度。需要包含角色和表空间的话9.1 的 pg_dump 是不导全局对象的要额外用 pg_dumpall 的 globals-onlyC:\Program Files\PostgreSQL\9.1\bin\pg_dumpall.exe -h 127.0.0.1 -U postgres --globals-only -f D:\backup\globals_913.sql--globals-only 只导出角色、组和表空间定义不导出表数据这个文件很小但迁移时必须有否则恢复出来的库没有原用户权限全乱。5.2 恢复到新实例及校验方法目标实例上先建一个空库再执行 pg_restore。命令和参数是这样C:\Program Files\PostgreSQL\9.1\bin\createdb.exe -h 127.0.0.1 -p 5433 -U postgres newdb pg_restore -h 127.0.0.1 -p 5433 -U postgres -d newdb --no-owner -j 4 D:\backup\mydb_913.dump--no-owner 忽略备份文件里的对象属主全部归到当前连接用户避免老实例里的用户名在新环境不存在时恢复中断。-j 4 是并行任务数custom 格式支持并行恢复四个线程同时建索引和导数据速度比单线程明显快。恢复完成后用 psql 校验行数和对象数量psql -h 127.0.0.1 -p 5433 -U postgres -d newdb -c SELECT count(*) FROM pg_tables WHERE schemanamepublic;比对手上老实例的 pg_tables 数量差距通常是视图中依赖的对象或扩展表。对象清单确认后随机抽三张业务表对比行数再检查序列是否落后。9.1 的序列在恢复后有时会停留在备份时的值而不是数据表最大 ID插入新数据时直接主键冲突。用这条 SQL 校准SELECT setval(seq.oid::regclass, max_val) FROM pg_class seq JOIN pg_namespace n ON n.oid seq.relnamespace JOIN pg_attribute att ON att.attrelid seq.relreplident, (SELECT max(id) AS max_val FROM mydb_table) t WHERE seq.relkind S AND att.attname last_value;seq.relkind S 筛选出序列对象把序列推进到业务表当前最大 ID避免插入时报 duplicate key。校准完再插入一条测试数据确认自增正常备份恢复流程才算真正闭环。我养成的一个习惯是凡是碰老版本实例先导出一份纯 SQL 文本备份再操作custom 格式留着给 pg_restore 用SQL 文本留着给最坏情况做手工修补。希望帮到你。本文还有配套的精品资源点击获取