企业官网建设流程全解析

简介：一份面向 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.3，JSONB、窗口函数、分区表、增量物化视图这些能力它一概没有，安全补丁也停止很久了。

选型时还要考虑一个现实因素：团队里有没有人熟悉旧工具链。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 "P@ssw0rd_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_P@ssw0rd'; -- 创建只读账号，代替让业务直接用超级用户 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 默认就支持 md5，scram 加密要等 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\data"

sc 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 --encoding=UTF8

执行完看到「Success. You can now start the database server」就说明数据目录初始化完成。再执行net start pgsql-9.1就能正常拉起来。这里--encoding=UTF8是我强烈建议追加的参数，它把数据库默认编码钉在 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\data"

pg_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 的实战拆解帮到你，少踩我踩过的坑。

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