简介一份面向 Windows 64 位环境的 PostgreSQL 9.1.3 安装资源包适用对象是需要在本地或服务器上部署开源关系型数据库的开发者、DBA 与运维人员可用于支撑业务系统或验证该版本特性。压缩包整体约 48.18MB共含 2 个文件exe 格式的安装程序用于启动安装流程htm 格式的说明文件则提供系统需求、许可协议及配置指引尤其适合初次安装时对照操作。目前已有 796 人次浏览/学习对 PostgreSQL 相关使用者具有一定参考意义。尽管 9.1.3 是相对早期的稳定版但已内置 MVCC 多版本并发控制、全文搜索、窗口函数、PL/pgSQL 存储过程语言及异步复制等核心特性能应对复杂查询和业务规则场景安装完成后可借助 pgAdmin 完成建表、导入导出与备份恢复还能参考社区文档进行参数调优。对于研究 PostgreSQL 历史版本、兼容旧环境或搭建轻量级数据库服务的用户这份离线资源包提供了可直接落地的安装介质与说明。1. 老版 PostgreSQL 的 Windows x64 安装包为什么 9.1.3 还有人找很多人搜 postgresql 下载哪个版本时会直接跳过 9.1.3但当某天你需要在一台 Windows x64 老服务器上把跑了十多年的业务系统数据库搭起来时只有这个版本的二进制才跟那套旧驱动兼容。这份资源不是什么新技术而是当年 EnterpriseDB 官方出品的 One-Click 安装版自带安装引导、数据目录初始化、pgAdmin 管理工具双击之后就能把整套 PostgreSQL 9.1.3 数据库服务装成 Windows 服务。它解决的是「老系统迁移、老应用对接、老代码重放」这类现实问题适合给老业务做环境复现的开发、运维和测试人员。用对了它是救场工具用错了它能让你在兼容性里折腾一整天。接下来我从安装、配置到排错完整拆一遍。2. 版本号的真实信息9.1.3-1 到底代表什么2.1 版本号拆解主版本、补丁版本和打包号9.1.3-1 这个写法里最前面 9.1 代表 PostgreSQL 的主版本线9.1.3 是这条版本线下的第三个补丁发布。最后面的 -1 是安装包打包编号意味着这是对 9.1.3 源码做的第一次 Windows 封装。别小看这个尾巴它代表着安装器本身有过一次修订常见的修订内容就是修复安装路径带空格、服务注册失败这类 Windows 平台问题。需要说清楚的是9.1 系列已经是 2012 年前后的产物它没有后来 9.2 的 json 类型、没有 9.3 的 LATERAL 查询特性。但如果你是给老驱动配老库版本新反而坏事。很多第三方系统当时只针对 libpq 的 9.1 接口做了测试换上高版本驱动后二进制通信协议都可能变化业务端报错让你根本无从下手。从部署角度看这个版本支持 Windows 7/Server 2008 R2 及之后的系统x64 安装包会默认把程序装到C:\Program Files\PostgreSQL\9.1数据目录独立放在D:\data\pgsql之类的位置也是推荐的。它自带 pgAdmin III 作为图形客户端虽然界面老但查表、看执行计划、编辑数据都够用。2.2 为什么一个 2012 年的数据库还在生产环境服役一个重要原因是升级成本被低估。某公司在 2022 年尝试从 9.1 升到 13应用层用的是某老牌报表组件连接串里写死了旧版本特性数据库升完报表模块直接白屏。后来不得不把 9.1.3 装回 Windows 镜像里继续跑老业务同时并行搭新库慢慢引流。这种事在金融、制造、政务系统里非常常见。另一个原因是扩展兼容性。PostgreSQL 9.1 时代的一些过程语言扩展和第三方插件在 9.1 之后经历过接口重构。比如某些内部开发的 C 语言扩展函数只针对 9.1 的版本编译过换到高版本就必须重新编译源码而源码往往已经找不到了。这类情况下旧版安装包就成了最后一套能跑的运行时。2.3 什么场景适合用它什么场景不该用适合的场景我归纳成三类老系统复现、旧数据迁移源、版本对照测试。不适合的就是新项目开发——新项目没有任何理由选 9.1.3JSONB、窗口函数、分区表、增量物化视图这些能力它一概没有安全补丁也停止很久了。选型时还要考虑一个现实因素团队里有没有人熟悉旧工具链。9.1 时代的 pgAdmin III 和后来 pgAdmin 4 操作逻辑差异很大新人不一定能适应。如果你只是临时拉个库把旧数据导出来装上 9.1.3 后配合pg_dump把数据导出到新版库这是最务实的用法下面的章节我会一步步展开。3. 在 Windows x64 上部署 9.1.3图形安装与静默安装3.1 安装前的三类检查动手安装之前我一般会强制检查三件事缺一件都可能装到一半翻车。第一是 VC 运行库。PostgreSQL 9.1 的 Windows 版安装包依赖 Microsoft Visual C 2008 SP1 运行库。有些精简版系统没有预装安装器会提示缺少msvcr90.dll。常见做法是提前装好 VC 2008 和 2010 的 x64 运行库宁可多装也不要少装。注意 9.1 这个年代x64 版本必须匹配 x64 运行库装成 x86 的照样报错。第二是端口占用。PostgreSQL 默认监听 5432。我见过太多案例是之前装过 MySQL 或其他数据库占了 5432安装时一路下一步没注意端口检测告警最后服务起来却是旧的实例。事前在命令行跑一下netstat -ano | findstr 5432有输出就先处理占用的进程。第三是权限。安装程序要写Program Files目录、要注册 Windows 服务就必须以管理员身份运行安装包。右键选择「以管理员身份运行」这一步不能省。用普通双击方式安装服务注册环节大概率失败而且报错信息很隐晦。3.2 图形安装全流程与每个页面的信息图形安装器是 BitRock InstallBuilder 做的流程比较直白我把关键页面的内容和该填什么说一遍# 1. 语言选择选 English不推荐选简体中文原因是 # 9.1 时代的中文翻译不完整夹杂英文反而更混乱 # 2. 安装目录C:\Program Files\PostgreSQL\9.1 # 这是默认路径非特殊原因不要改到中文目录下 # 3. 数据目录D:\pgsql\9.1\data # 生产环境务必把数据目录放到非系统盘便于备份和迁移 # 4. 管理密码为 postgres 超级用户设置密码 # 这里设置的密码就是之后 psql 登录要用的密码 # 5. 端口号5432除非和现有服务冲突否则保持默认 # 6. 区域设置建议选 [Default locale] 或 [C] # 如果业务要显示中文安装完再把编码参数单独设后面会讲这段代码其实就是对照安装界面做的填写清单。每填一项你都要清楚它影响什么安装目录影响程序文件位置数据目录影响所有数据库文件的位置密码是初始超级用户凭证端口决定了所有客户端连接串里的端口号。区域设置是这里最容易埋坑的很多人在这一步选了 Chinese (Simplified)_China.936装完默认 GBK 编码导入 UTF-8 数据时全是问号。安装器跑到最后一步会弹出「Stack Builder」的勾选界面它可以额外装 pgAdmin、PostGIS 等组件。如果你只是要数据库本体把这个勾去掉直接结束。Stack Builder 要联网从仓库拉组件网不好的时候会一直卡住正常的安装流程反而被它拖累。3.3 静默安装无人值守部署的完整参数如果你要在一批服务器上重复部署图形界点点点效率太低。安装器支持命令行静默安装我贴一套验证过可用的参数组合C:\path\to\postgresql-9.1.3-1-windows-x64.exe ^ --mode unattended ^ --unattendedmodeui none ^ --prefix C:\Program Files\PostgreSQL\9.1 ^ --datadir D:\pgsql\9.1\data ^ --superpassword Pssw0rd_2024 ^ --serverport 5432 ^ --enable-components server,pgAdmin参数含义拆开说--mode unattended告诉安装器不要弹出任何交互窗口--unattendedmodeui none连进度条都不显示完全静默--prefix指定安装目录--datadir指定数据目录--superpassword是 postgres 用户的初始密码--serverport是监听端口--enable-components选择要装的组件server 是必选pgAdmin 是老管理工具想省空间可以去掉。静默模式有个特点如果前面说过的依赖检查没过它不会像图形界面一样弹提示而是直接退出并返回非零退出码。因此静默安装前VC 运行库和端口占用检查必须做得更严格。我个人习惯是先跑一遍图形安装确认环境干净再对后续服务器用静默参数批量部署。3.4 安装目录、数据目录和服务的关系安装完成后系统里会出现三样东西。第一是C:\Program Files\PostgreSQL\9.1下的程序文件包括bin、lib、share目录其中的bin放着psql.exe、pg_dump.exe等命令行工具。第二是数据目录所有数据库的表文件、WAL 日志、配置文件都在这里。第三是 Windows 服务服务名通常是pgsql-9.1它负责自动拉起 postgres 进程。这三个位置要分开理解程序目录是只读的一般不会动数据目录是运维重点备份和恢复都针对它服务是中间层把 postgres 进程托管给 Windows 服务管理器。很多人误以为装完数据库重启后是程序自启其实是服务管理器把 postgres 启动了。排查启动问题时先看服务状态比看进程列表更直接。4. 初始化与基础加固让 9.1.3 稳定跑起来的关键配置4.1 postgresql.conf 高频项连接与内存安装完之后不要急着建库先检查data目录下的postgresql.conf。这个文件是整个数据库实例的总配置入口。我按重要级顺序讲几个每次部署都会调的项目-- data/postgresql.conf 中高频修改项 listen_addresses localhost -- 绑定地址只允许本机访问 port 5432 -- 监听端口必须和安装时设置一致 max_connections 100 -- 最大连接数老系统应用连接池要预留 shared_buffers 512MB -- 共享内存占物理内存建议 1/4 以内 work_mem 8MB -- 单次排序/哈希操作可用内存 maintenance_work_mem 128MB -- 维护操作如索引重建内存 wal_buffers 8MB -- WAL 日志缓冲区参数说明写到代码块里不方便展开这里补充一句。listen_addresses这个参数是安全的第一道门槛默认值是localhost也就是只有本机客户端能连。如果业务应用和数据库在同一台机器保持默认就对了如果应用在别的服务器要改成具体 IP 或*同时必须配合pg_hba.conf的权限规则一起改只改 listen 不改认证等于裸奔。shared_buffers的设置很多人照搬网上大内存参数直接填 2GB结果老机器物理内存只有 4GB系统开始疯狂换页。我的经验是 9.1 这个老版本内存管理不如新版本细腻shared_buffers别超过物理内存的四分之一超过之后性能提升不明显反而拖慢整体。work_mem也别贪大它是每个连接每次排序都可能申请的资源100 个连接同时排序8MB 乘以 100 就是 800MB 的瞬时内存开销。4.2 pg_hba.conf 认证规则与连接授权pg_hba.conf是访控白名单改它要极其谨慎。它的名字是「host-based authentication」的缩写规则是从上往下匹配匹配到第一条就不再往下看。默认安装时文件里有几行预置规则至少包含本机 postgres 用户的 trust 或 md5 认证。# data/pg_hba.conf 典型配置 # 类型 数据库 用户 地址 认证方式 local all all md5 host all all 127.0.0.1/32 md5 host all all 192.168.1.0/24 md5 host all all 0.0.0.0/0 reject这段配置表达的含义依次是Unix socket 本地连接都要 md5 密码认证本机 IP 上也要求密码内网这个网段允许带密码访问最后一行把所有来源的访问全部拒绝。reject放在最后是兜底的意思是除了前面明确放行的网段其他一律拒绝。这种「白名单加兜底拒绝」的写法是标准做法。注意 9.1 时代的 pg_hba 支持的认证方式有 trust、reject、md5、password、ident。md5是大多数场景的选择。trust不要出现在任何远程网段规则里它表示免密谁打进网段就能直接登库。很多人为了图方便把第一行改成host all all 0.0.0.0/0 trust测试测完忘改回来数据库等于裸奔。改完 pg_hba.conf 不会自动生效需要重载配置。最稳妥的方式是登录 psql 后执行SELECT pg_reload_conf();这个命令只重载配置不断开现有连接比重启服务温和得多。如果改完发现把自己锁在外面先慌不要重装看后面排查章里的恢复办法。4.3 修改 postgres 密码与回收权限安装时设置的管理员密码可能不符合安全要求正式接入业务前先改一遍。9.1 版本的改密语法费一点因为ALTER ROLE ... WITH PASSWORD的加密参数和后来版本略有不同但基本写法一致-- 用超级用户连接后执行 ALTER ROLE postgres WITH PASSWORD New_Strong_Pssw0rd; -- 创建只读账号代替让业务直接用超级用户 CREATE ROLE app_readonly WITH LOGIN PASSWORD ReadOnly_123 ; GRANT CONNECT ON DATABASE yourdb TO app_readonly; GRANT SELECT ON ALL TABLES IN SCHEMA public TO app_readonly; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO app_readonly;做这一步的原因是老版本数据库的日志审计能力弱如果所有业务都共享一个超级用户账号出了问题连是谁干的都查不出。给应用建独立账号、只授予必要权限是低成本高收益的加固方式。ALTER DEFAULT PRIVILEGES那句的意思是对未来新建的表自动授予只读权限这样以后加表不用重复授权。密码策略上9.1 版本没有内置密码复杂度校验只能靠管理员的自觉。长度不低于 12 位、包含大写小写数字和符号是底线。还有人问为什么不用password_encryption参数改成更高级的加密算法9.1 默认就支持 md5scram 加密要等 10 版本才有这一点想提也提不了。4.4 服务自启与手动启动的命令清单Windows 服务注册成功后日常启动和停止就围绕net命令展开# 查看服务状态 sc query pgsql-9.1 # 启动服务 net start pgsql-9.1 # 停止服务 net stop pgsql-9.1 # 手动启动数据库进程前台调试用不注册服务 C:\Program Files\PostgreSQL\9.1\bin\postgres.exe -D D:\pgsql\9.1\datasc query输出的状态里RUNNING表示服务正常STOPPED表示已停止START_PENDING是正在启动。如果卡在START_PENDING超过十几秒基本能判定数据目录或权限有问题直接看数据目录下的日志文件pg_log里有没有报错。手动启动 postgres.exe 的那条命令是调试用的前台运行、日志直接打在控制台能现场看到初始化错误排查完记得关掉窗口别让它和服务抢同一个数据目录。5. 常见问题排查老版本数据库在 Windows 上的五个典型坑5.1 服务启动失败提示数据目录不存在现象安装完成后尝试net start pgsql-9.1系统提示服务启动又停止事件查看器里看到「数据目录 D:\pgsql\9.1\data 不存在或无法访问」。原因最常见的是安装时填写的数据目录没有初始化成功。BitRock 安装器在静默模式下如果目标盘空间不足或路径有中文初始化这一步会静默跳过但服务注册已经完成于是服务指向一个空目录。解决不要改服务参数正确做法是用initdb手动初始化一次。初始化命令要指定认证方式和区域cd C:\Program Files\PostgreSQL\9.1\bin initdb.exe -D D:\pgsql\9.1\data -U postgres -A md5 --encodingUTF8执行完看到「Success. You can now start the database server」就说明数据目录初始化完成。再执行net start pgsql-9.1就能正常拉起来。这里--encodingUTF8是我强烈建议追加的参数它把数据库默认编码钉在 UTF-8能避开后面全文乱码的坑。5.2 端口 5432 被占用服务起来却是别的进程现象安装完成后能连上数据库但执行 SQL 报语法错误仔细一看netstat -ano发现监听 5432 的进程 PID 指向一个完全陌生的程序名。原因旧版 PostgreSQL 安装器自带的端口检测并不可靠如果 5432 被只有管理员权限才能看到的进程占用检测结果可能显示空闲安装器也就没有阻止。解决先确认真实占用者再处理netstat -ano | findstr :5432 tasklist /FI PID eq 查到的PID如果确认是无关程序关掉它再启动服务。也可以直接给 9.1.3 换个端口改postgresql.conf里的port 5433同时检查pg_hba.conf不涉及端口重启服务应用端连接串同步改。换端口比杀进程稳妥不会误伤其他服务。5.3 导入数据中文全是问号或乱码现象用pg_dump从旧库导出的 SQL 脚本导入 9.1.3表里的中文全部变成??????或者查询时出现「invalid byte sequence for encoding UTF8」。原因数据源数据库的编码是 GBK导出的 SQL 头里写了SET client_encoding GBK而在 9.1.3 里数据库默认编码是 UTF-8客户端与服务端编码转换时信息丢失。更直接的原因是安装时选择了 Chinese locale导致初始模板库 template1 的编码就是 GBK。解决新建数据库时显式指定编码CREATE DATABASE bussinessdb WITH ENCODING UTF8 LC_COLLATE C LC_CTYPE C TEMPLATE template0;LOCALE选 C 能避开 Windows 区域设置带来的排序和字符集干扰TEMPLATE template0是关键因为模板库 template1 已经带着安装时的编码改它是不允许继承的。导入数据前还要确认客户端的client_encoding与服务端一致执行SET client_encoding UTF8;再导。还有一种极端情况是数据本身已经坏了这只能回到源头重新导出没有后悔药。5.4 pg_hba.conf 改错导致谁都连不上现象改了 pg_hba.conf 之后pg_reload_conf执行完所有客户端连接全部超时本机 psql 也提示「no pg_hba.conf entry for host」。原因pg_hba.conf 的匹配规则写反或者只留了拒绝项比如把host all all 0.0.0.0/0 reject放到了最前面match 到这一条后所有远程连接直接拒绝本机规则在它后面根本没机会执行。解决如果只是连接被拒数据库服务本身还活着这时候加工是没有用的直接改文件。文件路径是D:\pgsql\9.1\data\pg_hba.conf先用文本编辑器打开把有问题的行注释或删除保留至少一行本机管理员的 md5 放行规则。保存后不需要重启服务在命令行执行C:\Program Files\PostgreSQL\9.1\bin\pg_ctl.exe reload -D D:\pgsql\9.1\datapg_ctl reload做的事和上面 SQL 里的pg_reload_conf()一样都是温和重载。如果连本机管理员用户都连不上说明文件里的local或127.0.0.1规则也被你误删了补救办法是在文件最顶部加一行临时信任规则local all all trust重载后连进去改好配置再删掉它。注意这一步只能本机操作远程别试。5.5 旧版安装文件在新 Windows 上安装报兼容性错误现象在 Windows 10 或更新的系统上双击安装包安装器弹出「此程序存在已知兼容性问题」或安装一半退出事件日志里是安装器服务崩溃。原因9.1.3 的安装器是在 Windows 7/Server 2008 R2 时代编译的它调用的某些系统 API 在新系统里行为改变。最常见的是安装器要写的配置文件路径涉及权限模型变化导致静默初始化子进程退出。解决右键安装包选择「属性 → 兼容性 → 更改所有用户的设置」勾选「以兼容模式运行这个程序」下拉选Windows 7同时勾选「以管理员身份运行此程序」。兼容模式能绕过大部分安装器崩溃问题。安装完数据库本体服务不受这个兼容模式影响因为服务是独立的但安装过程中生成的服务配置如果没写全仍可能出现上面的数据目录问题两件事要区分开。6. 收尾技巧把 9.1.3 的数据平滑迁到新版本环境如果你只是拿 9.1.3 做临时环境最后一步必然是数据迁移。我推荐的方式是逻辑备份用自带的pg_dump把业务库导出成 SQL 文件再导入到新版 PostgreSQL。这条路最安全不用担心二进制文件格式不兼容。:: 导出 9.1.3 的业务数据含建表语句和数据 C:\Program Files\PostgreSQL\9.1\bin\pg_dump.exe ^ -h localhost -p 5432 -U postgres -F c -b ^ -f D:\backup\businessdb_913.dump businessdb :: 导入到新版数据库先确认新库已建好 C:\Program Files\PostgreSQL\16\bin\pg_restore.exe ^ -h localhost -p 5432 -U postgres -d newbusinessdb ^ -c D:\backup\businessdb_913.dump-F c是自定义压缩格式导出速度比纯 SQL 快而且还能在恢复时指定只恢复某张表。-b参数强制包含大对象老系统里经常有存文件的大对象不写这个参数导出的备份是缺料的。导入端-c的意思是先 drop 目标表再重建适合空库或有旧结构的库做覆盖式恢复。迁移后必须做三件验证第一导出和导入分别执行计数对比比如SELECT count(*) FROM user_table两边得一致第二抽查几条含中文的字段肉眼确认不是乱码第三回放一遍业务端的核心查询看返回结果和字段类型是否正常。9.1 里的一些隐式类型转换和新版本行为不同最常见的例子是timestamp精度和boolean输出格式有差异应用层要考虑兼容。我自己的习惯是装完 9.1.3 后立刻做一把pg_dump备份测试确认备份能完整导出同时把这条命令写成一个批处理放进计划任务。后来真有次老库崩了靠这份备份十分钟内拉起临时环境给业务顶着从那以后我每次接老库迁移都会把「先验证备份可恢复」放在动手第一步。希望这份 9.1.3 的实战拆解帮到你少踩我踩过的坑。本文还有配套的精品资源点击获取
