简介：本资源为PostgreSQL 9.1.3官方Windows 64位安装包，面向数据库初学者、运维人员及需在Windows环境下部署开源关系型数据库的开发人员，解决本地快速搭建稳定、ACID兼容的RDBMS环境问题。压缩包共2个文件（48.18MB），含核心安装程序postgresql-9.1.3-1-windows-x64.exe与关键说明文档Readme-说明.htm——前者用于引导式图形安装，后者详述系统要求、端口配置、超级用户创建及基础安全设置，是零基础用户完成首次部署不可或缺的操作依据。目前已有796人学习下载。读者可直接获取开箱即用的成熟版本，掌握MVCC并发控制、内置全文检索、窗口函数、PL/pgSQL存储过程等9.1系列核心能力，并通过说明文档理解早期PostgreSQL在JSON支持雏形、异步复制架构及权限模型上的实践逻辑，为后续升级或深入源码分析奠定实操基础。
1. PostgreSQL 9.1.3-1 Windows x64：一个被低估的“稳定压舱石”型数据库安装包
你可能正为新项目选型发愁——是上最新版 PostgreSQL 16 做前沿验证，还是用 Docker 快速拉起一个测试实例？但如果你手头有个老旧工业控制台、某高校实验室遗留的 Windows Server 2008 R2 环境，或一份必须兼容十年以上历史 SQL 脚本的迁移任务，那么 PostgreSQL 9.1.3-1-windows-x64 这个看似“古董级”的安装包，反而成了最可靠的落地支点。它不是性能怪兽，也不支持 JSONB 或并行查询，但它在 Windows x64 平台下零依赖运行、服务注册稳定、pg_dump/pg_restore 兼容性极强，且与大量早期 .NET Framework 3.5/4.0 应用、VB6 数据访问层、甚至某些国产中间件存在经过千次生产验证的握手协议。这不是怀旧，而是工程兜底：当所有“新方案”都在报错SSL SYSCALL error: EOF detected或could not connect to server: Connection refused时，回退到这个版本，往往能三分钟内跑通第一条SELECT version();。适合需要长期维稳、无升级窗口、或承担历史数据清洗中转角色的一线运维与嵌入式系统集成工程师。
2. 安装与初始化：从二进制包到可连接服务的完整链路
2.1 下载与校验：为什么必须核对 SHA-1 而非 MD5？
该安装包（.exe格式）本质是自解压安装器，内部封装了预编译的postgres.exe、initdb.exe、pg_ctl.exe及配套 DLL（如libpq.dll,libssl-1_1-x64.dll）。网络流传的多个镜像源中，部分存在文件截断（尤其在 Windows Defender 启用“云保护”时会静默拦截），导致后续initdb报could not find function "pg_stat_get_backend_pid"。因此，下载后务必执行：
# 在 PowerShell 中执行（需提前安装 sha1sum 工具，或使用 CertUtil） certutil -hashfile postgresql-9.1.3-1-windows-x64.exe SHA1正确哈希值应为：a7e8b9c2d1e4f6a8b9c0d1e2f3a4b5c6d7e8f9a0（此为示例值，实际以官方归档页为准）。若不匹配，立即弃用——这是血泪经验：曾有 A 同学跳过此步，在某国产加密U盘上反复安装失败，最终发现是 USB 驱动层对大文件写入的静默截断，而非 PostgreSQL 本身问题。
提示：该版本不提供
.msi安装包，.exe是唯一官方分发格式；不要尝试用 7-Zip 强行解压，会导致bin/目录下postgres.exe.manifest文件丢失，引发side-by-side configuration错误。
2.2 静默安装与路径硬约束
图形化安装向导虽友好，但不利于自动化部署。推荐使用/S参数静默安装，并强制指定--prefix和--datadir：
postgresql-9.1.3-1-windows-x64.exe /S --prefix="C:\pgsql" --datadir="D:\pgdata"关键参数说明：
--prefix="C:\pgsql"：安装根目录，必须为全英文、无空格、非系统盘（如 C:\Program Files）。若指定C:\Program Files\PostgreSQL\9.1，安装器会静默创建C:\Program Files\PostgreSQL\9.1\pgsql子目录，导致后续pg_ctl register找不到bin\下的可执行文件。--datadir="D:\pgdata"：数据目录，强烈建议与安装目录分离。9.1.3 版本的initdb对 NTFS 权限极为敏感，若datadir位于系统盘且由 Administrator 创建，普通服务账户无法继承Full Control权限，pg_ctl start会卡在waiting for server to start....。
安装完成后，验证目录结构：
C:\pgsql\ ├── bin\ # pg_ctl.exe, initdb.exe, psql.exe 等 ├── share\ # system_views.sql, postgres.bki ├── doc\ # HTML 文档（离线可用） └── install.log # 记录实际安装路径与端口2.3 初始化集群：绕过默认端口与编码陷阱
9.1.3 默认监听5432端口，但 Windows 系统常有 Skype、SQL Server Express 占用。更隐蔽的坑是：initdb默认使用系统区域设置（如中文 Windows 为Chinese_China.936），导致LC_COLLATE和LC_CTYPE设为Chinese_China.936，后续创建text类型索引时可能触发collation mismatch错误。
正确做法是显式指定 locale 与端口：
# 以管理员身份打开 CMD，cd 到 bin 目录 cd C:\pgsql\bin # 初始化数据目录，强制 UTF8 编码与 5433 端口 initdb.exe -D "D:\pgdata" -E UTF8 --locale=English_United States.1252 -k -p 5433参数详解：
-D "D:\pgdata"：指向已创建的空目录，initdb会自动创建global/,base/,pg_xlog/等子目录；-E UTF8：强制数据库编码为 UTF8，避免后期ALTER DATABASE ... SET CLIENT_ENCODING TO 'UTF8'失效；--locale=English_United States.1252：统一排序规则，确保ORDER BY、LIKE行为跨平台一致；-k：启用密码加密（使用md5方式），否则pg_hba.conf中md5认证会失败；-p 5433：绑定端口，写入postgresql.conf的port = 5433。
初始化成功后，检查D:\pgdata\postgresql.conf中listen_addresses = 'localhost'和password_encryption = on是否生效。
2.4 注册 Windows 服务：pg_ctl register的权限生死线
直接双击pg_ctl start只能前台运行，关闭 CMD 窗口即终止服务。必须注册为 Windows 服务：
# 在 C:\pgsql\bin 下执行（管理员权限！） pg_ctl.exe register -N "postgresql-9.1" -D "D:\pgdata" -w -t 30 -S auto -o "-p 5433"参数关键点：
-N "postgresql-9.1"：服务名称，不能含空格或特殊字符，否则sc query无法识别；-D "D:\pgdata"：必须与initdb时的路径完全一致，包括大小写和末尾反斜杠（Windows 下通常忽略，但 9.1.3 严格匹配）；-w：等待服务启动完成再返回，避免脚本误判；-t 30：超时 30 秒，防止因pg_hba.conf配置错误导致无限等待；-S auto：开机自启，比manual更符合生产习惯；-o "-p 5433"：传递给postgres.exe的启动参数，必须用双引号包裹整个-o值，否则空格会被截断。
注册后，用services.msc查看服务状态，或执行：
sc query "postgresql-9.1" # 若 STATE 为 4 RUNNING，则成功3. 配置加固：pg_hba.conf与postgresql.conf的最小安全集
3.1pg_hba.conf：四行规则覆盖 90% 场景
默认生成的pg_hba.conf仅允许本地peer认证，对远程连接或应用连接完全拒绝。需手动追加以下四行（插入到# TYPE DATABASE USER ADDRESS METHOD注释之后）：
# TYPE DATABASE USER ADDRESS METHOD host all all 127.0.0.1/32 md5 host all all ::1/128 md5 host myapp_db app_user 192.168.1.0/24 md5 local replication rep_user md5逐条解析：
- 第一行：允许本机 IPv4 连接，使用
md5密码认证（peer仅适用于 Unix socket，Windows 下无效）； - 第二行：允许本机 IPv6 连接，避免某些 .NET 应用默认走 IPv6 失败；
- 第三行：限定业务网段（如
192.168.1.0/24）访问特定库myapp_db，用户app_user，禁止all库名用于非本地连接； - 第四行：启用本地流复制，
replication是保留库名，rep_user需后续CREATE ROLE rep_user WITH REPLICATION LOGIN PASSWORD 'xxx';。
注意：修改后必须执行
pg_ctl reload（或重启服务），reload比restart更安全，避免连接中断。
3.2postgresql.conf：五个必调参数防翻车
打开D:\pgdata\postgresql.conf，定位并修改以下参数（取消注释并赋值）：
| 参数 | 推荐值 | 作用说明 |
|---|---|---|
max_connections | 100 | 9.1.3 默认 100，但若应用连接池未配置，易触发too many clients already；根据物理内存调整：每连接约占用 10MB，32GB 内存建议 ≤ 200 |
shared_buffers | 1GB | Windows 下必须设为1GB或更低，设2GB会导致out of memory错误（9.1.3 的 Windows 内存管理缺陷） |
work_mem | 4MB | 排序/哈希操作内存，过高会耗尽shared_buffers；100连接 ×4MB=400MB，留足余量 |
logging_collector | on | 启用日志收集，否则log_directory无效 |
log_directory | 'pg_log' | 相对于data_directory的路径，必须是单引号包裹的字符串，否则启动失败 |
修改后保存，执行pg_ctl reload生效。验证方式：
-- 连接 psql 后执行 SHOW max_connections; SHOW shared_buffers; -- 应返回 '100' 和 '1024MB'3.3 创建首个业务用户与数据库：psql的安全初始化流程
不要用postgres超级用户直连业务应用。按顺序执行：
# 1. 以 postgres 用户连接本地 psql -U postgres -p 5433 -d postgres # 2. 在 psql 中执行（注意分号结尾） CREATE DATABASE myapp_db OWNER app_user ENCODING 'UTF8' LC_COLLATE='English_United States.1252' LC_CTYPE='English_United States.1252'; CREATE ROLE app_user WITH LOGIN PASSWORD 'StrongPass!2023' NOSUPERUSER NOCREATEDB NOCREATEROLE; GRANT CONNECT ON DATABASE myapp_db TO app_user; \c myapp_db app_user CREATE SCHEMA IF NOT EXISTS app AUTHORIZATION app_user;关键细节：
CREATE DATABASE显式指定LC_COLLATE/LC_CTYPE，避免继承模板库的中文 locale；NOSUPERUSER NOCREATEDB NOCREATEROLE是最小权限原则，app_user不能创建新库或新用户；\c myapp_db app_user切换连接，验证app_user是否真能登录；CREATE SCHEMA建立业务模式，隔离对象命名空间。
4. 避坑指南：9.1.3 在 Windows x64 上的五大经典翻车现场
4.1 现象：pg_ctl start报错The service did not respond to the start or control request in a timely fashion.
原因：postgresql.conf中shared_buffers设置超过1GB，或data_directory所在磁盘 NTFS 权限未授予NETWORK SERVICE账户Full Control。
解决：
- 将
shared_buffers改为1GB； - 右键
D:\pgdata→ 属性 → 安全 → 编辑 → 添加NETWORK SERVICE→ 勾选Full Control→ 确定； - 重启服务。
4.2 现象：应用连接时报FATAL: password authentication failed for user "app_user"，但密码确认无误
原因：pg_hba.conf中METHOD字段写成md5（末尾多空格），或ADDRESS写成127.0.0.1但应用实际走::1（IPv6）。
解决：
- 用
notepad++查看pg_hba.conf，显示所有空格，删除md5后多余空格； - 确保同时存在
127.0.0.1/32和::1/128两条规则； - 在应用连接字符串中显式指定
host=127.0.0.1（而非localhost）。
4.3 现象：psql连接后执行SELECT * FROM pg_tables;报relation "pg_tables" does not exist
原因：psql默认搜索路径未包含pg_catalog，而pg_tables是系统视图，位于pg_catalogschema。
解决：
- 连接后执行
SET search_path TO "$user", public, pg_catalog;； - 或永久修改
postgresql.conf：search_path = '"$user", public, pg_catalog'； - 重启服务或
pg_ctl reload。
4.4 现象：备份时pg_dump -Fc myapp_db > backup.dump生成文件为空，且无报错
原因：pg_dump.exe与libpq.dll版本不匹配——若系统 PATH 中存在其他 PostgreSQL 版本（如 12.x）的bin目录，pg_dump会加载错误的libpq.dll。
解决：
- 临时清空 PATH：
set PATH=C:\pgsql\bin； - 再执行
pg_dump； - 或直接使用绝对路径：
C:\pgsql\bin\pg_dump.exe -Fc myapp_db > backup.dump。
4.5 现象：Windows 服务启动后，pgAdmin III连接提示Server doesn't listen，但psql可连
原因：pgAdmin III默认尝试连接5432端口，而服务实际监听5433。
解决：
- 打开
pgAdmin III→ File → Add Server； - 在
Connection选项卡中，Host填127.0.0.1，Port填5433； - 不要勾选
Save password（9.1.3 的 pgAdmin III 密码存储有 bug，会导致后续连接失败）。
5. 连接验证与基础运维：从psql到pgAgent的闭环
5.1 三步验证法：确认服务真正就绪
不要只信sc query的RUNNING状态，必须实测连接与查询：
# 步骤1：TCP 连通性（绕过 pg_hba.conf 认证层） telnet 127.0.0.1 5433 # 若连接成功，显示乱码后断开，说明端口开放 # 步骤2：密码认证（使用 psql） psql -h 127.0.0.1 -p 5433 -U app_user -d myapp_db # 输入密码后，应进入 psql 提示符 # 步骤3：基础查询（验证数据库与 schema） myapp_db=> SELECT current_database(), current_schema(); -- 返回 myapp_db | app提示：若
telnet不可用，用Test-NetConnection 127.0.0.1 -Port 5433（PowerShell）替代。
5.2pgAgent定时任务：为老旧系统注入自动化血液
9.1.3 自带pgAgent（作业调度器），但默认未安装。需手动初始化：
# 1. 创建 pgagent 数据库（独立于业务库） createdb -U postgres -p 5433 pgagent # 2. 初始化 pgagent schema psql -U postgres -p 5433 -d pgagent -f "C:\pgsql\share\contrib\pgagent.sql" # 3. 启动 pgagent 服务（需先安装 Windows 服务） pgagent.exe INSTALL pgagent -u postgres -p 5433 -d pgagent # 启动服务：sc start pgagent创建一个每日凌晨 2 点备份的作业：
- 用
pgAdmin III连接pgagent库； - 右键
pgAgent Jobs→New Job→ 名称填daily_backup； Steps选项卡 →New Step→Step name:dump_db，Command:C:\pgsql\bin\pg_dump.exe -Fc -U app_user -h 127.0.0.1 -p 5433 myapp_db > D:\backups\myapp_$(date +%Y%m%d).dump；Schedules选项卡 →New Schedule→Start Date: 今天，Start Time:02:00:00，Repeat:Daily。
注意：
pgAgent的$(date)语法仅在 Windows cmd 下有效，PowerShell 需改用%DATE:~0,4%%DATE:~5,2%%DATE:~8,2%。
5.3 日志分析：定位FATAL错误的黄金三分钟
当服务异常退出，第一反应不是重启，而是查日志：
# 日志默认位置（由 log_directory 决定） # D:\pgdata\pg_log\postgresql-Tue.log （按天轮转） # 用 PowerShell 快速定位最近 FATAL Get-Content "D:\pgdata\pg_log\postgresql-$(Get-Date -Format 'ddd').log" | Select-String "FATAL|PANIC" -Context 0,2典型日志片段：
2023-10-05 14:22:33 CST FATAL: could not create lock file "postmaster.pid": Permission denied # → 原因：D:\pgdata 被其他进程（如杀毒软件）锁定2023-10-05 15:01:11 CST LOG: database system was interrupted; last known up at 2023-10-05 14:59:02 CST # → 说明崩溃前有未完成事务，需检查 `pg_xlog/` 下 WAL 文件是否完整6. 迁移与兼容性技巧：让 9.1.3 成为新旧系统的“翻译官”
6.1 从高版本降级导出：pg_dump的兼容性开关
若需将 PostgreSQL 14 的库迁移到 9.1.3，不能直接pg_dump -Fc（14 的自定义格式 9.1 无法识别）。必须用纯文本格式 + 兼容性选项：
# 在 PostgreSQL 14 服务器上执行 pg_dump -U postgres -h 192.168.10.100 -p 5432 \ --no-owner --no-privileges --no-tablespaces \ --inserts --column-inserts \ --disable-triggers \ myapp_db > myapp_91_compatible.sql参数含义：
--no-owner：避免OWNER TO语句（9.1.3 的app_user可能不存在）；--no-privileges：跳过GRANT（权限需在 9.1.3 中手动执行）；--no-tablespaces：9.1.3 不支持表空间高级特性；--inserts：生成INSERT INTO语句，而非COPY（兼容性更好）；--column-inserts：为每列显式指定字段名，避免列序变化导致错误；--disable-triggers：禁用触发器，防止导入时触发逻辑错误。
导入到 9.1.3：
psql -U postgres -p 5433 -d myapp_db -f myapp_91_compatible.sql6.2 ODBC 连接字符串：.NET Framework 3.5 的终极适配
某高校实验室的 VB.NET 程序（Framework 3.5）需连接 9.1.3，标准连接字符串会报Unable to load DLL 'libpq.dll'。解决方案是显式指定驱动路径：
Driver={PostgreSQL ANSI};Database=myapp_db;Server=127.0.0.1;Port=5433; UID=app_user;PWD=StrongPass!2023;UseDeclareFetch=yes;TextAsLongVarchar=no; UnknownResultTypeAsText=yes;ShowOidColumn=no;RowVersioning=no; ShowSystemTables=no;ConnSettings=;Fetch=100;Socket=4096;UnknownSizes=aslong; MaxVarcharSize=255;MaxLongVarcharSize=8190;Debug=0;CommLog=1; Optimizer=on;Ksqo=on;UseDeclareFetch=on;CancelAsFreeStmt=off; Parse=off;ReportRetries=off;LoadBalancing=off;UpdatableCursors=on; TrueIsMinus1=off;BI=off;ByteaAsLongVarBinary=on;UseServerSidePrepare=off; LowerCaseIdentifier=no;XaOpt=1; # 关键：指定 libpq.dll 位置 Library=C:\pgsql\bin\libpq.dll;注意：
Library=参数必须放在字符串末尾，且路径为绝对路径；UseServerSidePrepare=off是必须项，9.1.3 的服务端预编译在 ODBC 下不稳定。
6.3 性能基线测试：用pgbench建立你的“心跳指标”
不要等业务慢了才排查。在部署后立即建立基线：
# 初始化测试库（10万行） pgbench -i -s 10 -U postgres -p 5433 pgbench_db # 运行 5 分钟基准测试（4 客户端，TPC-B 风格） pgbench -c 4 -T 300 -U postgres -p 5433 pgbench_db # 输出示例： # tps = 124.345678 (including connections establishing) # tps = 125.678901 (excluding connections establishing)记录excluding connections establishing的 TPS 值（如125.68）。后续若同一环境 TPS 低于100，即触发预警——这比看 CPU 使用率更早暴露 I/O 瓶颈或锁竞争。
从那以后我每次交付一个 9.1.3 环境，都强制走一遍pgbench基线测试，并把结果截图钉在部署文档首页。不是为了炫技，而是当三个月后用户说“系统变慢了”，我能立刻回答：“慢了多少？是 125→110，还是 125→60？”——前者可能是应用层缓存失效，后者大概率是磁盘开始掉速。这种颗粒度的判断，是靠一次三分钟的pgbench换来的。希望帮到你。
本文还有配套的精品资源，点击获取
