简介：这份资源是面向64位Windows平台的PostgreSQL 9.1.3安装包，适合数据库初学者、后端开发人员及需要搭建本地测试环境的IT从业者，用于快速部署一套开源关系型数据库系统。压缩包内共2个文件，包含1个exe安装程序和1个htm说明文档，整体约48.18MB，exe用于执行安装流程，htm则提供安装指南、系统需求与许可协议等关键信息。该版本发布于2012年，具备MVCC多版本并发控制、全文搜索、窗口函数、触发器与存储过程、JSON数据类型、异步复制及PL/pgSQL编程等特性，并保持ACID事务兼容，可满足复杂查询与高可靠性场景。目前已有796人学习下载，读者可借此完成数据库安装配置、创建超级用户、设置端口与网络访问，并借助pgAdmin进行建表、导入导出与备份恢复，为后续数据库管理与开发打下基础。
1. 老版本 PostgreSQL 在 Windows x64 上到底还能不能跑
手上有一台内网 Windows Server，业务系统只认postgresql-9.1.3-1-windows-x64这个安装包，运维群里一问，十个人有八个劝你换新版。但现实是：老系统的 JDBC 驱动、存储过程语法、甚至某个字段的默认值行为，都跟 9.1 绑死了，升级不是不能做，是排期排到明年。这时候真正的问题不是「该不该用老版本」，而是「怎么在 Windows x64 上把它稳稳装起来、跑起来、连得上」。
这篇笔记就围绕postgresql-9.1.3-1-windows-x64这个具体安装包展开，讲清楚它在现代 Windows 环境下的安装路径、初始化参数、服务注册方式，以及用 Navicat 这类客户端连接时最容易翻车的几个点。适合两类人：一类是被老系统绑住、必须原地部署 9.1 的运维和开发；另一类是想拿老版本做兼容性验证、又不想污染主环境的工程师。新版 PostgreSQL 的安装教程网上已经够多了，老版本 x64 安装包在 Windows 上的坑，反而没人系统讲。
2. 安装包结构与 Windows x64 运行前提：先搞清楚你手里的是什么
2.1 这个安装包和新版安装器的本质区别
postgresql-9.1.3-1-windows-x64是 PostgreSQL 官方在 2012 年前后发布的 Windows 二进制安装包，命名规则是「主版本.次版本.修订号-打包序号-windows-架构」。它和现在 PostgreSQL 官网下载页那种带图形化向导的 installer 不是一回事——9.1 时代的 Windows 包更接近「解压即用 + 手动初始化」的模式，安装器本身只负责把二进制文件铺到目标目录，数据库集群（data 目录）需要你自己用initdb生成。
这一点非常关键。很多人拿到这个包，双击 exe 一路下一步，装完发现服务里没有 PostgreSQL，或者有服务但连不上，就是因为没意识到「装软件」和「建集群」是两步。新版安装器把这两步合并了，老版本没有。
安装包解压后典型目录结构是这样的：
| 目录/文件 | 作用 |
|---|---|
bin/ | 所有可执行文件，包括initdb.exe、pg_ctl.exe、psql.exe |
lib/ | 依赖库和扩展模块 |
share/ | 时区、字符集、SQL 脚本等共享资源 |
doc/ | 本地文档 |
uninstall.exe | 卸载入口 |
bin目录是整个部署的核心，后面所有命令都从这里发起。我一般会把这个目录加到系统 PATH，或者干脆在命令行里用绝对路径，避免版本冲突。
2.2 Windows x64 上的依赖与权限前提
9.1 时代的二进制包对系统组件有硬依赖，缺一个就直接闪退，而且报错信息往往很含糊。最常见的是缺Microsoft Visual C++ 2010 Redistributable (x64)——注意不是 2013 也不是 2015-2022，9.1 是用 VS2010 工具链编译的。如果你在 Windows 11 或 Server 2022 上部署，系统可能已经带了新版运行库，但 2010 版不一定有，需要单独装。
另一个前提是安装路径不能有中文和空格。老版本 PostgreSQL 对路径编码的处理很粗糙，C:\Program Files\PostgreSQL\9.1这种带空格的路径在某些子命令里会解析失败。我一般直接装到C:\pgsql91这种短路径，省掉后面一堆转义麻烦。
权限方面，如果你打算把 PostgreSQL 注册成 Windows 服务，安装和初始化阶段需要用管理员权限运行命令行。但数据库进程本身不建议用 Administrator 账户跑，常见做法是建一个专用的本地用户（比如pguser），把 data 目录的权限只给这个用户。9.1 在 Windows 上对权限继承比较敏感，data 目录如果被其他用户读写，启动时会报could not change permissions of directory之类的错。
提示：在 Windows 11 上部署 9.1 时，如果
initdb报could not find a suitable encoding，先检查系统区域设置里的「非 Unicode 程序语言」是不是中文，改成英文（美国）后重启命令行再试。
3. 从 initdb 到服务注册：把 9.1 集群在 Windows 上跑起来
3.1 用 initdb 生成 data 目录的最小命令
假设安装路径是C:\pgsql91，data 目录打算放在C:\pgsql91\data，用管理员命令行执行：
cd C:\pgsql91\bin initdb.exe -D C:\pgsql91\data -U postgres -E UTF8 --locale=Chinese_China.936 -A md5这条命令做了四件事：-D指定 data 目录；-U指定超级用户名（默认是当前 Windows 用户，显式指定更可控）；-E UTF8指定数据库编码；--locale指定区域；-A md5指定本地认证方式为密码认证。
参数说明和常见取值：
| 参数 | 含义 | 老版本 Windows 上的注意点 |
|---|---|---|
-D | data 目录路径 | 必须为空目录，路径不能有中文 |
-U | 超级用户名 | 不要用中文，不要和 Windows 用户名混淆 |
-E | 数据库编码 | 建议 UTF8，和--locale要匹配 |
--locale | 区域设置 | 中文环境常用Chinese_China.936，但和 UTF8 组合时可能报警告 |
-A | 认证方式 | md5最通用，trust只适合本地调试 |
这里有个经典矛盾：--locale=Chinese_China.936配-E UTF8，initdb 会提示 locale 和 encoding 不匹配。9.1 的处理方式是允许你继续，但排序规则会按 936 走。如果业务对中文排序不敏感，直接用--locale=C配 UTF8 最省事，避免后续一堆编码告警。
执行成功后，data 目录里会出现postgresql.conf、pg_hba.conf、PG_VERSION等文件。PG_VERSION里写的是9.1，这个文件决定了这个 data 目录只能被 9.1 的二进制读取，后面升级大版本时不能直接复用。
3.2 注册 Windows 服务并设置开机自启
9.1 在 Windows 上注册服务用pg_ctl register，不是sc create：
pg_ctl.exe register -N "postgresql-9.1" -D C:\pgsql91\data -S auto -U ".\pguser" -P "你的密码"-N是服务名，-D是 data 目录，-S auto表示自动启动，-U和-P是运行服务的 Windows 账户和密码。注意-U这里填的是 Windows 账户，不是数据库的 postgres 用户，格式用.\用户名表示本地账户。
注册完用net start postgresql-9.1启动。如果启动失败，第一件事是看 Windows 事件查看器里的应用程序日志，9.1 会把详细错误写进去，比命令行直接报的server did not start有用得多。
启动成功后，用 psql 验证：
psql.exe -U postgres -h 127.0.0.1 -p 5432 -d postgres能进去就说明集群活了。这时候postgresql.conf里的listen_addresses默认是localhost，只允许本机连。要让局域网其他机器连过来，改成listen_addresses = '*'，同时pg_hba.conf里加一行host all all 0.0.0.0/0 md5，然后重启服务。这两步缺一不可，只改一个就连不上。
3.3 用 Navicat 连接 9.1 时的驱动与认证配置
Navicat 连 PostgreSQL 走的是 libpq 协议，9.1 的协议版本比较老，新版 Navicat 默认的 SSL 设置可能会直接拒绝连接。常见做法是在 Navicat 连接属性里把「SSL」关掉，或者把「使用 SSL」设为「不使用」。
连接参数填法：
| 字段 | 值 |
|---|---|
| 主机 | 服务器 IP 或 127.0.0.1 |
| 端口 | 5432（默认） |
| 初始数据库 | postgres |
| 用户名 | postgres |
| 密码 | initdb 后第一次设的密码 |
如果报authentication failed，先确认pg_hba.conf里对应来源的认证方式是md5而不是trust或peer。9.1 的pg_hba.conf修改后需要pg_ctl reload或重启服务才生效，reload 对认证配置是够的。
注意：Navicat 17 及以上版本在连接 9.1 时，如果服务端没开 SSL，客户端又强制 SSL，会报
SSL error: wrong version number。解决办法是在连接的高级设置里显式关闭 SSL，不要用「自动」。
4. 老版本 PostgreSQL 在 Windows 上的避坑与排查
4.1 服务启动报「could not create shared memory」
现象：net start postgresql-9.1失败，事件日志里写could not create shared memory segment。
原因：9.1 在 Windows 上用的是 System V 共享内存的模拟实现，shared_buffers设得太大，或者系统开了太多其他占共享内存的程序，就会分配失败。Windows 上 9.1 的shared_buffers上限比 Linux 低得多。
解决：把postgresql.conf里的shared_buffers从默认的 32MB 降到 16MB 甚至 8MB，重启服务。如果还不行，检查max_connections是不是设得过高，连接数乘以每连接内存也会吃共享内存。
4.2 initdb 报「invalid locale name」
现象：执行initdb时提示invalid locale name: Chinese_China.936。
原因：Windows 的区域名称和 PostgreSQL 期望的格式不完全一致，9.1 对 locale 名称的解析比较死板，某些 Windows 版本上Chinese_China.936不被识别。
解决：改用--locale=C或--locale=Chinese (Simplified)_China.936，或者干脆不指定 locale，让 initdb 用系统默认。如果业务必须用中文排序，建议在数据库创建时用LC_COLLATE单独指定，而不是在 initdb 阶段硬编码。
4.3 psql 连接报「no pg_hba.conf entry for host」
现象：本机 psql 能连，局域网其他机器连报no pg_hba.conf entry for host "192.168.x.x"。
原因：pg_hba.conf默认只允许127.0.0.1/32和::1/128，没有放行局域网网段。
解决：在pg_hba.conf末尾加host all all 192.168.0.0/16 md5，然后pg_ctl reload -D C:\pgsql91\data。注意 reload 不会断开已有连接，但新连接会按新规则走。如果加了还不生效，检查是不是改错了文件——9.1 的 data 目录里可能同时存在pg_hba.conf和pg_hba.conf.orig，别改到备份文件。
4.4 服务账户权限导致 data 目录不可写
现象：服务能启动，但一写数据就报could not open file "base/...": Permission denied。
原因：注册服务时用的 Windows 账户对 data 目录没有写权限，或者 data 目录被其他账户占用过，NTFS 权限继承乱了。
解决：右键 data 目录 → 属性 → 安全 → 高级 → 禁用继承 → 删除所有继承的权限，然后只给服务账户和 Administrators 完全控制。改完重启服务。9.1 在 Windows 上对权限的检查比新版严格，data 目录的 owner 必须和服务运行账户一致。
4.5 卸载后残留服务导致重装失败
现象：卸载 9.1 后重新安装，pg_ctl register报service already exists。
原因：卸载程序没有清理 Windows 服务注册表项，服务名还占着。
解决：用sc delete postgresql-9.1手动删掉残留服务，再重新注册。如果sc delete报拒绝访问，用管理员命令行执行。删完最好重启一次再装，避免句柄没释放。
5. 让 9.1 在 Windows 上跑得更稳的几个进阶习惯
5.1 用 pg_ctl 做日常启停而不是 net start
net start走的是 Windows 服务控制管理器，出错时信息少。日常维护我习惯直接用pg_ctl：
pg_ctl.exe start -D C:\pgsql91\data -l C:\pgsql91\log\startup.log pg_ctl.exe stop -D C:\pgsql91\data -m fast pg_ctl.exe status -D C:\pgsql91\data-l把启动日志写到文件，出问题时直接看这个文件，比事件查看器快。-m fast是快速关闭，会回滚未提交事务，比smart更适合维护窗口。status能告诉你进程 PID 和 data 目录，确认服务到底有没有在跑。
5.2 定期用 pg_dump 做逻辑备份，别只靠文件拷贝
9.1 在 Windows 上没有 PITR 的成熟方案，物理备份（直接拷 data 目录）必须停服务，而且跨版本不可恢复。我一般配一个每天凌晨的pg_dump：
pg_dump.exe -U postgres -h 127.0.0.1 -F c -b -v -f C:\backup\pgsql91_%date:~0,4%%date:~5,2%%date:~8,2%.backup postgres-F c是自定义格式，支持并行恢复和选择性恢复；-b包含大对象；-v输出详细过程。备份文件用日期命名，保留最近 7 天。恢复时用pg_restore，注意 9.1 的pg_restore不能恢复比它新的大版本导出的文件，所以备份和恢复必须用同一套二进制。
5.3 监控 checkpointer 和后台写进程的状态
9.1 的pg_stat_bgwriter视图能看出检查点压力：
SELECT checkpoints_timed, checkpoints_req, buffers_checkpoint, buffers_clean FROM pg_stat_bgwriter;如果checkpoints_req远大于checkpoints_timed，说明max_wal_size（9.1 里叫checkpoint_segments）设小了，检查点被频繁触发，I/O 会抖。9.1 的checkpoint_segments默认是 3，老硬件上建议调到 10 到 16，但别超过 32，否则崩溃恢复时间会拉长。这个参数改完需要重启，不能 reload。
5.4 用 pgAdmin III 而不是新版 pgAdmin 管理 9.1
新版 pgAdmin 4 对 9.1 的支持在 2020 年后就陆续断了，连上去经常报协议不兼容。9.1 时代的官方客户端是 pgAdmin III，虽然界面老，但功能完整，能管表、看执行计划、导数据。如果只是日常查数据，Navicat 够用；要做 schema 管理和性能分析，pgAdmin III 更稳。
我自己的习惯是：装完 9.1 后先把pg_hba.conf和postgresql.conf各备份一份到C:\pgsql91\conf_backup，每次改配置前先对比 diff。老版本没有ALTER SYSTEM，所有参数改动都得手动编辑文件再 reload，没有后悔药。这套流程我用了好几年，帮好几个内网系统续了命。希望帮到你。
本文还有配套的精品资源，点击获取
