简介postgresql-9.1.3-1-windows-x64压缩包是面向64位Windows平台的开源关系型数据库PostgreSQL 9.1.3稳定版安装资源主要服务需要在Windows环境搭建或学习数据库的开发者、运维人员与IT学习者。压缩包仅2个文件核心为exe安装程序另附一份htm格式说明文档整体约48.18MB说明文档详细列出安装步骤、系统需求与许可协议方便首次使用者按图索骥完成部署。该版本具备MVCC并发控制、全文搜索、窗口函数、PL/pgSQL存储过程语言等能力支持异步复制与ACID事务在高并发读写下仍能保证数据一致性与完整性窗口函数可简化累计、排名等跨行计算全文搜索便于文本检索异步复制则可用于搭建只读副本支撑负载均衡或灾备场景。借助说明文档还能学习数据目录配置、端口调整、连接参数设置及超级用户创建并在安装后通过pgAdmin等工具执行建表、导入导出、备份恢复覆盖日常运维关键环节文档也会提醒硬件资源要求、端口开放策略与强密码设置等注意事项帮助规避安装失败和安全遗漏。目前已有796人学习下载该版本虽然发布较早但核心机制成熟稳定适合从入门到进阶的数据库用户在Windows 64位环境中复现老系统部署或开展学习实验。1. postgresql-9.1.3-1-windows-x64这个老版本为什么还有人在找还在搜 postgresql-9.1.3-1-windows-x64 这个安装包的人大概率不是图新鲜而是手上有台老 Windows 服务器、一套跑了好几年的业务系统或者一个只能装 9.1 的受限环境。这个版本是 2012 年初的补丁版生命周期早已结束可直到今天依然有从业者在纠结 postgresql 下载哪个版本、能不能继续用。我的观点一向是业务没坏就别乱动但你必须先把它的安装、配置和迁出路径摸透。这篇文章讲的就是这条路让 9.1.3 在 Windows x64 上稳定跑起来再安全地把数据带出来。2. 安装前准备装之前必须做对的四件事老版本安装最怕的不是版本老而是准备工作没做透。很多人双击安装包就开始点下一步结果装到一半回滚或者装完服务起不来最后只能骂骂咧咧地卸载重来。下面四项检查每一项都能省掉后面至少一小时的排查时间。2.1 安装包命名的信息量9.1.3 和末尾的 -1 分别指什么安装包文件名里有两段信息9.1.3 是 PostgreSQL 的版本号9 指大版本1 指特性版本3 指补丁版本末尾的 -1 是 Windows 安装器自身的构建序号和数据库版本没有关系。排查问题时不需要去纠结 -1 代表什么只需要确认一件事你拿到的确实是 9.1.x 分支的 x64 安装包。选择哪个 PostgreSQL 版本核心判断依据是你的业务需求。9.1 发布于 2011 年9.1.3 作为补丁版发布于 2012 年它的特性停留在那个时代没有 JSONB、没有分区表原生支持、没有并行查询、没有逻辑复制。如果你的业务只用了简单的表、索引、视图、存储过程和触发器9.1 完全够用如果应用方要求新特性那就别在老版本上硬撑直接规划迁移。还有一点值得注意9.1 的 Windows 安装器在 Server 2008 R2 和 Windows 7 x64 上表现最稳定在 Windows 10/11 上也能装但可能出现兼容性提示。新系统上装老版本不是不行而是你得接受它偶尔闹脾气。2.2 Windows x64 兼容性哪些系统能跑、哪些不建议硬装这个安装包是 x64 版本意味着 64 位系统是前提。Windows 7 x64、Windows Server 2008 R2 及之后的 64 位系统都能安装但我的建议是生产环境优先考虑 Windows Server驱动和服务权限更可控。Windows 10/11 的桌面系统也能运行适合本地开发测试不适合作为线上数据库服务器。32 位和 64 位的坑不在服务端而在客户端。如果你的业务程序是 32 位应用通过 TCP 方式连接 64 位 PostgreSQL 服务端没有问题因为 libpq 走的是网络协议但如果你的程序用 ODBC 连接32 位应用必须安装 32 位版本的 PostgreSQL ODBC 驱动和数据库服务端是 64 位无关。这是最容易搞混的点。系统内存方面9.1 在 Windows 上的共享内存实现决定了它不像 Linux 那样能轻松吃到几十 GB 内存。物理内存 8GB 以下的机器9.1 跑得很轻松内存越大越要小心 shared_buffers 的取值这会在第四章详细讲。2.3 VC 运行库检查9.1 依赖的老运行库经常缺席老版本 Windows 安装包几乎都依赖对应版本的 VC 运行库9.1 也不例外。常见报错是双击安装包或启动服务时提示无法启动此程序因为计算机中丢失 MSVCR90.dll。很多人在新机器上装完最新的 VC 2015-2022 运行库以为万事大吉实际上 9.1 需要的是那个年代的 VC2008 运行库二者互不替代。检查方法是打开程序和功能看有没有安装对应版本的 Visual C Redistributable。如果你不确定缺不缺可以先试试启动安装程序报错再补装也可以直接查看 C:\Windows\System32 下有没有 msvcr90.dll 文件。顺带提醒有些精简版系统会把这些运行库删掉装数据库之前先补运行库是通用习惯别等到起服务时才一脸懵。2.4 目录规划安装目录和数据目录必须分开9.1 安装器默认把数据库数据放在 C:\Program Files\PostgreSQL\9.1\data 下这个位置很尴尬。Program Files 目录带 UAC 权限保护数据库进程写数据时可能被拦而且系统盘空间有限数据库日志和 WAL 文件增长起来很快。我一般会在数据盘单独建一个目录比如 D:\pgdata\9.1。安装时把数据目录指到这个位置。如果已经按默认安装完也不要慌可以用 initdb 重新初始化一个新数据目录再把服务注册到新目录上这个流程第三章会给出完整命令。路径选择上还有两个细节目录路径尽量不要带中文虽然 PostgreSQL 支持但某些第三方备份工具和脚本会因编码问题翻车目录路径不要带空格比如避免 D:\My Data\pg因为系统服务和命令行工具解析带空格的路径时容易出错。3. 安装与初始化从安装包到能连库的最小路径这一章解决核心问题怎么把这个安装包变成一台能连、能建表、能跑业务的数据库。两条路都给你图形安装器适合单台机器initdb 加 pg_ctl register 的组合适合需要精确控制的场景。3.1 交互式安装的完整走查每一步该选什么双击安装包后安装器会引导你完成配置。有几个界面需要特别留意。第一是安装目录默认是 C:\Program Files\PostgreSQL\9.1建议保持默认即可程序文件放在系统盘问题不大关键是数据目录要改到独立位置。第二是数据目录安装器会让你选择数据库文件的存放位置这里务必指向你准备好的数据盘目录比如 D:\pgdata\9.1。第三是超级用户密码postgres 用户的密码要设置得复杂一些因为这是数据库的最高权限账号同时把密码记到密码管理工具里别指望自己能记住。端口默认 5432如果本机已经被其他实例占用改成 5433 或 5434 都可以但要确保防火墙和连接串里同步修改。Locale 选择是整场安装里最关键的一步安装器默认会跟随系统区域在简体中文 Windows 上会得到 GBK 编码的数据库后患无穷。我的建议是选择与 UTF8 对应的选项或者在安装完成后用 initdb 重建数据目录。安装完成后安装器会自动注册 Windows 服务并启动数据库。看到成功安装不代表一切正常一定要按 3.4 节的验证步骤确认一遍。3.2 用 initdb 手动建库适合服务器环境的初始化图形安装器偶尔会在权限和编码上自作主张所以我更推荐在服务器上用 initdb 手动初始化数据目录尤其是当你需要完全掌控数据目录位置和编码时。命令如下C:\Program Files\PostgreSQL\9.1\bin\initdb.exe -D D:\pgdata\9.1 -E UTF8 --localeC -U postgres -A md5 --pwfileC:\temp\pgpass.txt逻辑说明initdb 的作用是初始化一个空的数据目录生成 postgresql.conf、pg_hba.conf、基础系统数据库等必备文件。-D 指定数据目录位置目录必须为空或不存在-E UTF8 指定数据库默认编码为 UTF8--localeC 指定使用 C 语言环境避免中文 Windows 默认 locale 带来的排序和编码问题-U postgres 指定超级用户名为 postgres-A md5 指定默认认证方式为 md5 密码认证--pwfile 从文件读取密码避免密码出现在命令行历史中。参数说明如果你确定业务不需要 UTF8也可以把 -E 改成你需要的编码但大多数现代应用都以 UTF8 为佳。-A 参数建议必选 md5不要用 trust否则本地任何用户都能免密登录。-U postgres 可以改成其他用户名但后续连接工具默认都识别 postgres非必要不要改。执行成功后数据目录下会出现 postgresql.conf 和 pg_hba.conf 两个文件后续配置都改这里。如果 initdb 报错先检查数据目录是否为空、当前 Windows 用户是否有该目录的写权限。3.3 pg_ctl register 注册 Windows 服务initdb 只是生成了数据目录还需要把数据库注册成 Windows 服务让它开机自启、随系统管理。命令如下C:\Program Files\PostgreSQL\9.1\bin\pg_ctl.exe register -N postgresql-x64-9.1 -D D:\pgdata\9.1 -U NT AUTHORITY\NetworkService -S auto逻辑说明pg_ctl 是 PostgreSQL 的服务控制工具register 子命令用于注册 Windows 服务。-N 指定服务名称我习惯用 postgresql-x64-9.1和图形安装器生成的服务名保持一致方便后续识别-D 指定数据目录必须和 initdb 时一致-U 指定服务运行的系统账号这里用 NetworkService它是 Windows 内置账号权限受限但足够 PostgreSQL 运行安全性更好-S auto 表示服务随系统自动启动。参数说明如果不加 -U默认以本地系统账号运行权限过大且某些网络访问行为受限。用 NetworkService 时必须确认该账号对数据目录 D:\pgdata\9.1 有完全控制权限否则服务启动时无法读写数据文件。设置目录权限的方法是右键数据目录在安全选项卡里添加 NetworkService 账号并赋予完全控制。服务注册完成后可以通过net start postgresql-x64-9.1启动服务net stop postgresql-x64-9.1停止服务。也可以进入服务管理界面查看服务状态确认启动类型是否为自动。3.4 安装后的三分钟验证别急着交差服务启动之后先用最简单的命令确认数据库真的能用。打开命令提示符执行C:\Program Files\PostgreSQL\9.1\bin\psql.exe -h localhost -p 5432 -U postgres -d postgres -c select version();这条命令用 psql 连接本机 5432 端口的 postgres 数据库执行版本查询。如果能看到 PostgreSQL 9.1.3 的版本信息说明服务端启动正常、认证配置正确、客户端连接链路通畅。接下来检查端口监听状态netstat -ano | findstr 5432正常应该看到 TCP 0.0.0.0:5432 或 127.0.0.1:5432 的监听记录。如果只看到 127.0.0.1说明 listen_addresses 还没放开远程连接不了这个在第四章处理。最后测试建表和简单查询psql -h localhost -U postgres -d postgres -c create table test_check(id int); drop table test_check;逻辑说明建表再删表确认数据目录可写、事务可提交。如果这步报错大概率是数据目录权限问题回到 3.3 节检查 NetworkService 账号权限。三分钟验证做完这台数据库才算是真正能干活了。4. 让 9.1 跑顺配置文件的真实调参这一章聚焦 9.1 在 Windows x64 上最常见的配置调整。配置文件只有两个postgresql.conf 管性能和行为pg_hba.conf 管谁能连。改之前先备份原文件改完之后用 reload 方式加载尽量不重启服务。4.1 postgresql.conf 必调参数从默认配置到能扛业务9.1 的默认配置非常保守只能保证服务能启动扛不住真实业务。打开 D:\pgdata\9.1\postgresql.conf找到以下几组参数按你的机器配置调整。shared_buffers 256MB work_mem 16MB maintenance_work_mem 64MB checkpoint_segments 32 checkpoint_completion_target 0.9 fsync on逻辑说明shared_buffers 是 PostgreSQL 的共享缓存池9.1 在 Windows 上受共享内存实现限制不宜设置过大物理内存 8GB 的机器建议 256MB 到 1GB 之间超过物理内存四分之一容易导致启动失败。work_mem 是单次排序和哈希操作可用的内存默认只有 1MB复杂查询很容易落盘调到 16MB 是安全起点但要注意这个值是每个排序操作独立计算的并发高时总内存消耗会放大。maintenance_work_mem 用于建索引、VACUUM 等维护操作64MB 是合理起步值。checkpoint_segments 控制 WAL 日志在触发检查点前可累积的段数9.1 默认只有 3相当于 48MB写入频繁时会导致检查点过于频繁、磁盘 IO 飙升调到 32 能明显缓解。checkpoint_completion_target 表示检查点要在多长时间窗口内完成0.9 能更平滑地分散写入压力。fsync 保持 on这是数据安全底线千万别关。参数说明9.1 没有 max_wal_size 和 min_wal_size 这两个参数它们是后面大版本才引入的照着新版本文档调会直接报参数不存在。如果你需要做基于 WAL 的持续归档备份还需要把 wal_level 从默认的 minimal 改为 archive同时配置 archive_mode 和 archive_command注意这个调整需要重启数据库才能生效。4.2 pg_hba.conf认证规则的最小改动pg_hba.conf 控制客户端连接认证方式。9.1 安装器生成的默认配置通常只允许本机 127.0.0.1 和 ::1 连接本地连接认证方式可能是 trust 或 md5。你需要按业务需要做两件事放开局域网访问、收紧本地认证。# 原默认配置 host all all 127.0.0.1/32 md5 host all all ::1/128 md5 # 新增局域网网段访问 host all all 192.168.1.0/24 md5逻辑说明pg_hba.conf 从上到下逐行匹配连接请求只要命中第一行匹配规则就不再往下看所以常用规则放在前面。host 表示 TCP 连接all 表示所有数据库后面的 all 表示所有用户192.168.1.0/24 是允许访问的网段md5 表示密码认证。参数说明如果你只想让某一个 IP 连把网段写成具体的 IP 加 /32比如 192.168.1.100/32。如果局域网环境可信可以用 trust 免密但生产环境强烈不建议。改完 pg_hba.conf 不需要重启只执行 reload 即可C:\Program Files\PostgreSQL\9.1\bin\pg_ctl.exe reload -D D:\pgdata\9.1同时记得把 postgresql.conf 里的 listen_addresses 从默认的 localhost 改成 *否则即使 pg_hba.conf 放开了网段服务端也不会监听对外网卡这个改动需要重启数据库生效。4.3 Windows 下的日志与编码三个容易被忽略的运维习惯9.1 的日志默认写在数据目录下的 pg_log 文件夹里文件名形如 postgresql-2012-03-12_000000.log按天和序号滚动。出问题时先看这个目录日志里没有报错再看 Windows 事件查看器的应用程序日志这个排查顺序能覆盖大部分启动失败场景。编码方面如果你在 initdb 时用了 -E UTF8 --localeC那数据库内部编码就是 UTF8。但 Windows 客户端的默认 client_encoding 可能仍然是 GBK导致写入的数据乱码。解决办法是在连接串里显式指定编码或者在 psql 里执行set client_encoding to UTF8;。应用程序连接 PostgreSQL 时JDBC 连接串可以加 characterEncodingUTF-8ODBC 则在连接配置里选择 Unicode 驱动。时区也是一个容易踩的地方。9.1 默认 timezone 跟随操作系统时区如果你的服务器设在虚拟机上且时区混乱数据库返回的时间会跟着错。建议在 postgresql.conf 里显式设置 timezone比如 timezone Asia/Shanghai统一到一个固定值避免依赖系统设置。4.4 9.1 与现代版本的行为差异调试时别拿新思维套老版本9.1 和现在的新版本在语法层面有不少差异调试老系统时最容易犯的错就是拿新版本的特性去套 9.1。例如 9.1 不支持CREATE INDEX IF NOT EXISTS也不支持ALTER TABLE ... DROP COLUMN IF EXISTS的完整语义从新版本迁移过来的脚本在 9.1 上执行会直接语法报错。认证方式的差异同样关键。9.1 的密码认证只认识 md5 和 trust不认识新版本默认的 scram-sha-256。如果你从高版本复制一份 pg_hba.conf 到 9.1服务端会直接报 unsupported authentication method导致所有连接失败。反过来高版本客户端连接 9.1 时如果客户端强制要求 SCRAM 认证也会握手失败。处理办法是统一让客户端使用 md5 兼容模式或者在连接串里指定认证方式。权限模型也有差异。9.1 的默认权限控制比新版本宽松public schema 上对 public 角色默认有 CREATE 权限任何能连上来的用户都能在 public schema 里建表。安全要求高的场景需要手动REVOKE CREATE ON SCHEMA public FROM PUBLIC;。这个细节在新版本里已经默认收紧所以老版本接手后一定要检查一遍权限。5. 常见问题排查9.1.x 在 Windows x64 上最容易翻车的五个点老版本在 Windows 上跑的痛基本都是这几个问题。每一条都按现象、原因、解决三步展开你可以直接按症状对号入座。5.1 服务启动即停止日志里却什么都没有现象服务管理器里点击启动状态从正在启动弹回已停止去数据目录的 pg_log 文件夹看日志文件是空的或者只有几行初始化信息。Windows 事件查看器里也看不到具体报错。原因八成的概率是数据目录权限不对。Windows 服务以 NetworkService 账号运行而这个账号对数据目录 D:\pgdata\9.1 没有写权限导致 postgres 进程初始化共享内存或创建日志文件失败。还有两成概率是 shared_buffers 设置过大、超出了 Windows 分配给该服务的资源限额。解决先检查数据目录的 ACL 权限给 NetworkService 账号添加完全控制权限然后重启服务。如果权限没问题把 postgresql.conf 里 shared_buffers 改成 128MB 再试。两者都不行用命令pg_ctl -D D:\pgdata\9.1 start前台启动报错信息会直接打到终端比翻日志直观得多。5.2 远程连接超时netstat 看到 5432 只监听 127.0.0.1现象本机 psql 连接正常局域网里其他机器 telnet 数据库服务器 IP 的 5432 端口不通netstat 发现监听地址是 127.0.0.1:5432 而不是 0.0.0.0:5432。原因postgresql.conf 里的 listen_addresses 默认值是 localhost只监听了回环地址对外网卡完全没有监听。另一个原因是 Windows 防火墙没有放行 5432 端口连接请求到了服务器网卡但被防火墙拦截了。解决把 postgresql.conf 里的 listen_addresses 改成 *重启数据库。然后确认防火墙入站规则里有 TCP 5432 的放行规则。老版本安装器偶尔会创建防火墙规则但也有不创建的情况手动添加最稳防火墙高级设置里新建入站规则端口选 TCP 5432允许连接。改完检查 netstat确认监听地址变成 0.0.0.0:5432 再测试远程连接。5.3 中文乱码locale 选错建库之后一路乱到今天现象数据库连上后查出来的中文是乱码写入中文报character with byte sequence 0x... in encoding GBK has no equivalent in UTF8或者反过来UTF8 中文在 GBK 客户端下变成问号。原因安装时 locale 跟随了中文 Windows 系统默认值initdb 初始化出来的数据库编码是 GBK而客户端连接串用的是 UTF8两边对不上。这个问题的根源在初始化阶段选错了编码后期只能靠转换补救。解决已经跑起来的库先确认服务端编码和客户端编码分别执行show server_encoding;和show client_encoding;。服务端如果是 GBK客户端连上后执行set client_encoding to GBK;能缓解乱码但这不是长久之计。根本解法是按第三章的 initdb 命令重建数据目录用 -E UTF8 --localeC 初始化然后通过逻辑导出导入把数据挪过去。记住这个教训任何新装实例的数据目录初始化时就必须把 UTF8 定死。5.4 pg_hba.conf 报 unsupported authentication method现象修改 pg_hba.conf 后 reload所有客户端连接都失败数据库日志里出现 unsupported authentication method 的报错。原因pg_hba.conf 里写了 9.1 不认识的认证方式。最常见的操作是从新版本数据库复制配置过来把服务器新版本默认的 scram-sha-256 带到了 9.1。9.1 只认识 trust、md5、password、reject 这些老认证方式遇到 scram 直接拒绝。解决打开 pg_hba.conf把所有认证方式统一改成 md5保存后 reload。同时检查客户端连接配置高版本客户端默认可能请求 SCRAM配合服务端 md5 时需要客户端允许使用 md5 认证。最稳妥的办法是让客户端 libpq 版本不要过高或者明确在连接参数里指定认证方式。排查这个问题时可以先看一眼日志里具体是哪一行规则报错修正后逐个测试。5.5 pg_dump 版本不匹配备份刚开始就翻车现象打算把 9.1 数据导出来迁移执行 pg_dump 时直接报错大致意思是 server version is 9.1.3, but pg_dump version is 14.x不让你继续备份。原因系统 PATH 环境变量里指向的是新版本 PostgreSQL 的 bin 目录你敲 pg_dump 时实际调用的是高版本的 pg_dump。PostgreSQL 为了保证备份一致性不允许用差异过大的客户端版本连接服务端做备份。解决备份时明确使用 9.1 安装目录下的 pg_dump 可执行文件C:\Program Files\PostgreSQL\9.1\bin\pg_dump.exe -h localhost -p 5432 -U postgres -F c -b -v -f D:\backup\app_9_1.dump appdb逻辑说明-F c 表示自定义压缩格式便于之后用 pg_restore 选择性地恢复-b 表示包含大对象-v 输出详细日志-f 指定备份文件路径最后一个参数 appdb 是要备份的数据库名。执行前先用pg_dump.exe --version确认版本号是 9.1.3再执行备份。如果你希望恢复时更方便可以不加 -F c直接输出纯 SQL 格式但自定义格式更灵活我推荐保持 -F c。6. 进阶用法从 9.1 平滑迁到新版本的工具链老版本总有一天要交班迁移是最有价值的高级操作。我的思路是逻辑备份为中间媒介目标版本用新库接住全程不做 in-place 升级降低风险。6.1 迁移前先做一次家底体检迁移前必须知道这个库里有什么。执行下面这条 SQL把数据库里的对象摸一遍select count(*) as total_tables from information_schema.tables where table_schema not in (pg_catalog,information_schema);这条命令统计业务 schema 下的表数量。再看有没有大对象和扩展select count(*) from pg_largeobject_metadata; select extname from pg_extension;如果发现大量大对象备份时务必带 -b 参数如果扩展列表里有非内置扩展目标库也要安装对应版本。这一步决定你后面备份命令怎么写。6.2 用 9.1 原配 pg_dump 做逻辑备份迁移备份的命令和第五章的日常备份一样必须用 9.1 自带的 pg_dumpC:\Program Files\PostgreSQL\9.1\bin\pg_dump.exe -h localhost -U postgres -F c -b -v -f D:\backup\app_9_1.dump appdb备份完成后先检查文件大小是否正确再用 pg_restore 的 --list 参数预览内容确认里面包含了预期中的表和索引。6.3 用新版本 psql 恢复与校验在目标新版本实例上创建同名数据库然后用 pg_restore 恢复C:\Program Files\PostgreSQL\16\bin\psql.exe -h localhost -U postgres -c create database appdb; C:\Program Files\PostgreSQL\16\bin\pg_restore.exe -h localhost -U postgres -d appdb -v D:\backup\app_9_1.dump恢复完成后对比表行数和关键数据。先在老库执行C:\Program Files\PostgreSQL\9.1\bin\psql.exe -h localhost -U postgres -d appdb -c select count(*) from main_table;再到新库执行同样语句数字一致才算迁移成功。迁移期间老库不要停确认新库跑通了再切换连接串。我坚持的习惯是老库保留至少一周新库跑几天再决定是否清理老环境这个习惯帮我躲过多次迁移返工。希望帮到你。本文还有配套的精品资源点击获取
简介postgresql-9.1.3-1-windows-x64压缩包是面向64位Windows平台的开源关系型数据库PostgreSQL 9.1.3稳定版安装资源主要服务需要在Windows环境搭建或学习数据库的开发者、运维人员与IT学习者。压缩包仅2个文件核心为exe安装程序另附一份htm格式说明文档整体约48.18MB说明文档详细列出安装步骤、系统需求与许可协议方便首次使用者按图索骥完成部署。该版本具备MVCC并发控制、全文搜索、窗口函数、PL/pgSQL存储过程语言等能力支持异步复制与ACID事务在高并发读写下仍能保证数据一致性与完整性窗口函数可简化累计、排名等跨行计算全文搜索便于文本检索异步复制则可用于搭建只读副本支撑负载均衡或灾备场景。借助说明文档还能学习数据目录配置、端口调整、连接参数设置及超级用户创建并在安装后通过pgAdmin等工具执行建表、导入导出、备份恢复覆盖日常运维关键环节文档也会提醒硬件资源要求、端口开放策略与强密码设置等注意事项帮助规避安装失败和安全遗漏。目前已有796人学习下载该版本虽然发布较早但核心机制成熟稳定适合从入门到进阶的数据库用户在Windows 64位环境中复现老系统部署或开展学习实验。1. postgresql-9.1.3-1-windows-x64这个老版本为什么还有人在找还在搜 postgresql-9.1.3-1-windows-x64 这个安装包的人大概率不是图新鲜而是手上有台老 Windows 服务器、一套跑了好几年的业务系统或者一个只能装 9.1 的受限环境。这个版本是 2012 年初的补丁版生命周期早已结束可直到今天依然有从业者在纠结 postgresql 下载哪个版本、能不能继续用。我的观点一向是业务没坏就别乱动但你必须先把它的安装、配置和迁出路径摸透。这篇文章讲的就是这条路让 9.1.3 在 Windows x64 上稳定跑起来再安全地把数据带出来。2. 安装前准备装之前必须做对的四件事老版本安装最怕的不是版本老而是准备工作没做透。很多人双击安装包就开始点下一步结果装到一半回滚或者装完服务起不来最后只能骂骂咧咧地卸载重来。下面四项检查每一项都能省掉后面至少一小时的排查时间。2.1 安装包命名的信息量9.1.3 和末尾的 -1 分别指什么安装包文件名里有两段信息9.1.3 是 PostgreSQL 的版本号9 指大版本1 指特性版本3 指补丁版本末尾的 -1 是 Windows 安装器自身的构建序号和数据库版本没有关系。排查问题时不需要去纠结 -1 代表什么只需要确认一件事你拿到的确实是 9.1.x 分支的 x64 安装包。选择哪个 PostgreSQL 版本核心判断依据是你的业务需求。9.1 发布于 2011 年9.1.3 作为补丁版发布于 2012 年它的特性停留在那个时代没有 JSONB、没有分区表原生支持、没有并行查询、没有逻辑复制。如果你的业务只用了简单的表、索引、视图、存储过程和触发器9.1 完全够用如果应用方要求新特性那就别在老版本上硬撑直接规划迁移。还有一点值得注意9.1 的 Windows 安装器在 Server 2008 R2 和 Windows 7 x64 上表现最稳定在 Windows 10/11 上也能装但可能出现兼容性提示。新系统上装老版本不是不行而是你得接受它偶尔闹脾气。2.2 Windows x64 兼容性哪些系统能跑、哪些不建议硬装这个安装包是 x64 版本意味着 64 位系统是前提。Windows 7 x64、Windows Server 2008 R2 及之后的 64 位系统都能安装但我的建议是生产环境优先考虑 Windows Server驱动和服务权限更可控。Windows 10/11 的桌面系统也能运行适合本地开发测试不适合作为线上数据库服务器。32 位和 64 位的坑不在服务端而在客户端。如果你的业务程序是 32 位应用通过 TCP 方式连接 64 位 PostgreSQL 服务端没有问题因为 libpq 走的是网络协议但如果你的程序用 ODBC 连接32 位应用必须安装 32 位版本的 PostgreSQL ODBC 驱动和数据库服务端是 64 位无关。这是最容易搞混的点。系统内存方面9.1 在 Windows 上的共享内存实现决定了它不像 Linux 那样能轻松吃到几十 GB 内存。物理内存 8GB 以下的机器9.1 跑得很轻松内存越大越要小心 shared_buffers 的取值这会在第四章详细讲。2.3 VC 运行库检查9.1 依赖的老运行库经常缺席老版本 Windows 安装包几乎都依赖对应版本的 VC 运行库9.1 也不例外。常见报错是双击安装包或启动服务时提示无法启动此程序因为计算机中丢失 MSVCR90.dll。很多人在新机器上装完最新的 VC 2015-2022 运行库以为万事大吉实际上 9.1 需要的是那个年代的 VC2008 运行库二者互不替代。检查方法是打开程序和功能看有没有安装对应版本的 Visual C Redistributable。如果你不确定缺不缺可以先试试启动安装程序报错再补装也可以直接查看 C:\Windows\System32 下有没有 msvcr90.dll 文件。顺带提醒有些精简版系统会把这些运行库删掉装数据库之前先补运行库是通用习惯别等到起服务时才一脸懵。2.4 目录规划安装目录和数据目录必须分开9.1 安装器默认把数据库数据放在 C:\Program Files\PostgreSQL\9.1\data 下这个位置很尴尬。Program Files 目录带 UAC 权限保护数据库进程写数据时可能被拦而且系统盘空间有限数据库日志和 WAL 文件增长起来很快。我一般会在数据盘单独建一个目录比如 D:\pgdata\9.1。安装时把数据目录指到这个位置。如果已经按默认安装完也不要慌可以用 initdb 重新初始化一个新数据目录再把服务注册到新目录上这个流程第三章会给出完整命令。路径选择上还有两个细节目录路径尽量不要带中文虽然 PostgreSQL 支持但某些第三方备份工具和脚本会因编码问题翻车目录路径不要带空格比如避免 D:\My Data\pg因为系统服务和命令行工具解析带空格的路径时容易出错。3. 安装与初始化从安装包到能连库的最小路径这一章解决核心问题怎么把这个安装包变成一台能连、能建表、能跑业务的数据库。两条路都给你图形安装器适合单台机器initdb 加 pg_ctl register 的组合适合需要精确控制的场景。3.1 交互式安装的完整走查每一步该选什么双击安装包后安装器会引导你完成配置。有几个界面需要特别留意。第一是安装目录默认是 C:\Program Files\PostgreSQL\9.1建议保持默认即可程序文件放在系统盘问题不大关键是数据目录要改到独立位置。第二是数据目录安装器会让你选择数据库文件的存放位置这里务必指向你准备好的数据盘目录比如 D:\pgdata\9.1。第三是超级用户密码postgres 用户的密码要设置得复杂一些因为这是数据库的最高权限账号同时把密码记到密码管理工具里别指望自己能记住。端口默认 5432如果本机已经被其他实例占用改成 5433 或 5434 都可以但要确保防火墙和连接串里同步修改。Locale 选择是整场安装里最关键的一步安装器默认会跟随系统区域在简体中文 Windows 上会得到 GBK 编码的数据库后患无穷。我的建议是选择与 UTF8 对应的选项或者在安装完成后用 initdb 重建数据目录。安装完成后安装器会自动注册 Windows 服务并启动数据库。看到成功安装不代表一切正常一定要按 3.4 节的验证步骤确认一遍。3.2 用 initdb 手动建库适合服务器环境的初始化图形安装器偶尔会在权限和编码上自作主张所以我更推荐在服务器上用 initdb 手动初始化数据目录尤其是当你需要完全掌控数据目录位置和编码时。命令如下C:\Program Files\PostgreSQL\9.1\bin\initdb.exe -D D:\pgdata\9.1 -E UTF8 --localeC -U postgres -A md5 --pwfileC:\temp\pgpass.txt逻辑说明initdb 的作用是初始化一个空的数据目录生成 postgresql.conf、pg_hba.conf、基础系统数据库等必备文件。-D 指定数据目录位置目录必须为空或不存在-E UTF8 指定数据库默认编码为 UTF8--localeC 指定使用 C 语言环境避免中文 Windows 默认 locale 带来的排序和编码问题-U postgres 指定超级用户名为 postgres-A md5 指定默认认证方式为 md5 密码认证--pwfile 从文件读取密码避免密码出现在命令行历史中。参数说明如果你确定业务不需要 UTF8也可以把 -E 改成你需要的编码但大多数现代应用都以 UTF8 为佳。-A 参数建议必选 md5不要用 trust否则本地任何用户都能免密登录。-U postgres 可以改成其他用户名但后续连接工具默认都识别 postgres非必要不要改。执行成功后数据目录下会出现 postgresql.conf 和 pg_hba.conf 两个文件后续配置都改这里。如果 initdb 报错先检查数据目录是否为空、当前 Windows 用户是否有该目录的写权限。3.3 pg_ctl register 注册 Windows 服务initdb 只是生成了数据目录还需要把数据库注册成 Windows 服务让它开机自启、随系统管理。命令如下C:\Program Files\PostgreSQL\9.1\bin\pg_ctl.exe register -N postgresql-x64-9.1 -D D:\pgdata\9.1 -U NT AUTHORITY\NetworkService -S auto逻辑说明pg_ctl 是 PostgreSQL 的服务控制工具register 子命令用于注册 Windows 服务。-N 指定服务名称我习惯用 postgresql-x64-9.1和图形安装器生成的服务名保持一致方便后续识别-D 指定数据目录必须和 initdb 时一致-U 指定服务运行的系统账号这里用 NetworkService它是 Windows 内置账号权限受限但足够 PostgreSQL 运行安全性更好-S auto 表示服务随系统自动启动。参数说明如果不加 -U默认以本地系统账号运行权限过大且某些网络访问行为受限。用 NetworkService 时必须确认该账号对数据目录 D:\pgdata\9.1 有完全控制权限否则服务启动时无法读写数据文件。设置目录权限的方法是右键数据目录在安全选项卡里添加 NetworkService 账号并赋予完全控制。服务注册完成后可以通过net start postgresql-x64-9.1启动服务net stop postgresql-x64-9.1停止服务。也可以进入服务管理界面查看服务状态确认启动类型是否为自动。3.4 安装后的三分钟验证别急着交差服务启动之后先用最简单的命令确认数据库真的能用。打开命令提示符执行C:\Program Files\PostgreSQL\9.1\bin\psql.exe -h localhost -p 5432 -U postgres -d postgres -c select version();这条命令用 psql 连接本机 5432 端口的 postgres 数据库执行版本查询。如果能看到 PostgreSQL 9.1.3 的版本信息说明服务端启动正常、认证配置正确、客户端连接链路通畅。接下来检查端口监听状态netstat -ano | findstr 5432正常应该看到 TCP 0.0.0.0:5432 或 127.0.0.1:5432 的监听记录。如果只看到 127.0.0.1说明 listen_addresses 还没放开远程连接不了这个在第四章处理。最后测试建表和简单查询psql -h localhost -U postgres -d postgres -c create table test_check(id int); drop table test_check;逻辑说明建表再删表确认数据目录可写、事务可提交。如果这步报错大概率是数据目录权限问题回到 3.3 节检查 NetworkService 账号权限。三分钟验证做完这台数据库才算是真正能干活了。4. 让 9.1 跑顺配置文件的真实调参这一章聚焦 9.1 在 Windows x64 上最常见的配置调整。配置文件只有两个postgresql.conf 管性能和行为pg_hba.conf 管谁能连。改之前先备份原文件改完之后用 reload 方式加载尽量不重启服务。4.1 postgresql.conf 必调参数从默认配置到能扛业务9.1 的默认配置非常保守只能保证服务能启动扛不住真实业务。打开 D:\pgdata\9.1\postgresql.conf找到以下几组参数按你的机器配置调整。shared_buffers 256MB work_mem 16MB maintenance_work_mem 64MB checkpoint_segments 32 checkpoint_completion_target 0.9 fsync on逻辑说明shared_buffers 是 PostgreSQL 的共享缓存池9.1 在 Windows 上受共享内存实现限制不宜设置过大物理内存 8GB 的机器建议 256MB 到 1GB 之间超过物理内存四分之一容易导致启动失败。work_mem 是单次排序和哈希操作可用的内存默认只有 1MB复杂查询很容易落盘调到 16MB 是安全起点但要注意这个值是每个排序操作独立计算的并发高时总内存消耗会放大。maintenance_work_mem 用于建索引、VACUUM 等维护操作64MB 是合理起步值。checkpoint_segments 控制 WAL 日志在触发检查点前可累积的段数9.1 默认只有 3相当于 48MB写入频繁时会导致检查点过于频繁、磁盘 IO 飙升调到 32 能明显缓解。checkpoint_completion_target 表示检查点要在多长时间窗口内完成0.9 能更平滑地分散写入压力。fsync 保持 on这是数据安全底线千万别关。参数说明9.1 没有 max_wal_size 和 min_wal_size 这两个参数它们是后面大版本才引入的照着新版本文档调会直接报参数不存在。如果你需要做基于 WAL 的持续归档备份还需要把 wal_level 从默认的 minimal 改为 archive同时配置 archive_mode 和 archive_command注意这个调整需要重启数据库才能生效。4.2 pg_hba.conf认证规则的最小改动pg_hba.conf 控制客户端连接认证方式。9.1 安装器生成的默认配置通常只允许本机 127.0.0.1 和 ::1 连接本地连接认证方式可能是 trust 或 md5。你需要按业务需要做两件事放开局域网访问、收紧本地认证。# 原默认配置 host all all 127.0.0.1/32 md5 host all all ::1/128 md5 # 新增局域网网段访问 host all all 192.168.1.0/24 md5逻辑说明pg_hba.conf 从上到下逐行匹配连接请求只要命中第一行匹配规则就不再往下看所以常用规则放在前面。host 表示 TCP 连接all 表示所有数据库后面的 all 表示所有用户192.168.1.0/24 是允许访问的网段md5 表示密码认证。参数说明如果你只想让某一个 IP 连把网段写成具体的 IP 加 /32比如 192.168.1.100/32。如果局域网环境可信可以用 trust 免密但生产环境强烈不建议。改完 pg_hba.conf 不需要重启只执行 reload 即可C:\Program Files\PostgreSQL\9.1\bin\pg_ctl.exe reload -D D:\pgdata\9.1同时记得把 postgresql.conf 里的 listen_addresses 从默认的 localhost 改成 *否则即使 pg_hba.conf 放开了网段服务端也不会监听对外网卡这个改动需要重启数据库生效。4.3 Windows 下的日志与编码三个容易被忽略的运维习惯9.1 的日志默认写在数据目录下的 pg_log 文件夹里文件名形如 postgresql-2012-03-12_000000.log按天和序号滚动。出问题时先看这个目录日志里没有报错再看 Windows 事件查看器的应用程序日志这个排查顺序能覆盖大部分启动失败场景。编码方面如果你在 initdb 时用了 -E UTF8 --localeC那数据库内部编码就是 UTF8。但 Windows 客户端的默认 client_encoding 可能仍然是 GBK导致写入的数据乱码。解决办法是在连接串里显式指定编码或者在 psql 里执行set client_encoding to UTF8;。应用程序连接 PostgreSQL 时JDBC 连接串可以加 characterEncodingUTF-8ODBC 则在连接配置里选择 Unicode 驱动。时区也是一个容易踩的地方。9.1 默认 timezone 跟随操作系统时区如果你的服务器设在虚拟机上且时区混乱数据库返回的时间会跟着错。建议在 postgresql.conf 里显式设置 timezone比如 timezone Asia/Shanghai统一到一个固定值避免依赖系统设置。4.4 9.1 与现代版本的行为差异调试时别拿新思维套老版本9.1 和现在的新版本在语法层面有不少差异调试老系统时最容易犯的错就是拿新版本的特性去套 9.1。例如 9.1 不支持CREATE INDEX IF NOT EXISTS也不支持ALTER TABLE ... DROP COLUMN IF EXISTS的完整语义从新版本迁移过来的脚本在 9.1 上执行会直接语法报错。认证方式的差异同样关键。9.1 的密码认证只认识 md5 和 trust不认识新版本默认的 scram-sha-256。如果你从高版本复制一份 pg_hba.conf 到 9.1服务端会直接报 unsupported authentication method导致所有连接失败。反过来高版本客户端连接 9.1 时如果客户端强制要求 SCRAM 认证也会握手失败。处理办法是统一让客户端使用 md5 兼容模式或者在连接串里指定认证方式。权限模型也有差异。9.1 的默认权限控制比新版本宽松public schema 上对 public 角色默认有 CREATE 权限任何能连上来的用户都能在 public schema 里建表。安全要求高的场景需要手动REVOKE CREATE ON SCHEMA public FROM PUBLIC;。这个细节在新版本里已经默认收紧所以老版本接手后一定要检查一遍权限。5. 常见问题排查9.1.x 在 Windows x64 上最容易翻车的五个点老版本在 Windows 上跑的痛基本都是这几个问题。每一条都按现象、原因、解决三步展开你可以直接按症状对号入座。5.1 服务启动即停止日志里却什么都没有现象服务管理器里点击启动状态从正在启动弹回已停止去数据目录的 pg_log 文件夹看日志文件是空的或者只有几行初始化信息。Windows 事件查看器里也看不到具体报错。原因八成的概率是数据目录权限不对。Windows 服务以 NetworkService 账号运行而这个账号对数据目录 D:\pgdata\9.1 没有写权限导致 postgres 进程初始化共享内存或创建日志文件失败。还有两成概率是 shared_buffers 设置过大、超出了 Windows 分配给该服务的资源限额。解决先检查数据目录的 ACL 权限给 NetworkService 账号添加完全控制权限然后重启服务。如果权限没问题把 postgresql.conf 里 shared_buffers 改成 128MB 再试。两者都不行用命令pg_ctl -D D:\pgdata\9.1 start前台启动报错信息会直接打到终端比翻日志直观得多。5.2 远程连接超时netstat 看到 5432 只监听 127.0.0.1现象本机 psql 连接正常局域网里其他机器 telnet 数据库服务器 IP 的 5432 端口不通netstat 发现监听地址是 127.0.0.1:5432 而不是 0.0.0.0:5432。原因postgresql.conf 里的 listen_addresses 默认值是 localhost只监听了回环地址对外网卡完全没有监听。另一个原因是 Windows 防火墙没有放行 5432 端口连接请求到了服务器网卡但被防火墙拦截了。解决把 postgresql.conf 里的 listen_addresses 改成 *重启数据库。然后确认防火墙入站规则里有 TCP 5432 的放行规则。老版本安装器偶尔会创建防火墙规则但也有不创建的情况手动添加最稳防火墙高级设置里新建入站规则端口选 TCP 5432允许连接。改完检查 netstat确认监听地址变成 0.0.0.0:5432 再测试远程连接。5.3 中文乱码locale 选错建库之后一路乱到今天现象数据库连上后查出来的中文是乱码写入中文报character with byte sequence 0x... in encoding GBK has no equivalent in UTF8或者反过来UTF8 中文在 GBK 客户端下变成问号。原因安装时 locale 跟随了中文 Windows 系统默认值initdb 初始化出来的数据库编码是 GBK而客户端连接串用的是 UTF8两边对不上。这个问题的根源在初始化阶段选错了编码后期只能靠转换补救。解决已经跑起来的库先确认服务端编码和客户端编码分别执行show server_encoding;和show client_encoding;。服务端如果是 GBK客户端连上后执行set client_encoding to GBK;能缓解乱码但这不是长久之计。根本解法是按第三章的 initdb 命令重建数据目录用 -E UTF8 --localeC 初始化然后通过逻辑导出导入把数据挪过去。记住这个教训任何新装实例的数据目录初始化时就必须把 UTF8 定死。5.4 pg_hba.conf 报 unsupported authentication method现象修改 pg_hba.conf 后 reload所有客户端连接都失败数据库日志里出现 unsupported authentication method 的报错。原因pg_hba.conf 里写了 9.1 不认识的认证方式。最常见的操作是从新版本数据库复制配置过来把服务器新版本默认的 scram-sha-256 带到了 9.1。9.1 只认识 trust、md5、password、reject 这些老认证方式遇到 scram 直接拒绝。解决打开 pg_hba.conf把所有认证方式统一改成 md5保存后 reload。同时检查客户端连接配置高版本客户端默认可能请求 SCRAM配合服务端 md5 时需要客户端允许使用 md5 认证。最稳妥的办法是让客户端 libpq 版本不要过高或者明确在连接参数里指定认证方式。排查这个问题时可以先看一眼日志里具体是哪一行规则报错修正后逐个测试。5.5 pg_dump 版本不匹配备份刚开始就翻车现象打算把 9.1 数据导出来迁移执行 pg_dump 时直接报错大致意思是 server version is 9.1.3, but pg_dump version is 14.x不让你继续备份。原因系统 PATH 环境变量里指向的是新版本 PostgreSQL 的 bin 目录你敲 pg_dump 时实际调用的是高版本的 pg_dump。PostgreSQL 为了保证备份一致性不允许用差异过大的客户端版本连接服务端做备份。解决备份时明确使用 9.1 安装目录下的 pg_dump 可执行文件C:\Program Files\PostgreSQL\9.1\bin\pg_dump.exe -h localhost -p 5432 -U postgres -F c -b -v -f D:\backup\app_9_1.dump appdb逻辑说明-F c 表示自定义压缩格式便于之后用 pg_restore 选择性地恢复-b 表示包含大对象-v 输出详细日志-f 指定备份文件路径最后一个参数 appdb 是要备份的数据库名。执行前先用pg_dump.exe --version确认版本号是 9.1.3再执行备份。如果你希望恢复时更方便可以不加 -F c直接输出纯 SQL 格式但自定义格式更灵活我推荐保持 -F c。6. 进阶用法从 9.1 平滑迁到新版本的工具链老版本总有一天要交班迁移是最有价值的高级操作。我的思路是逻辑备份为中间媒介目标版本用新库接住全程不做 in-place 升级降低风险。6.1 迁移前先做一次家底体检迁移前必须知道这个库里有什么。执行下面这条 SQL把数据库里的对象摸一遍select count(*) as total_tables from information_schema.tables where table_schema not in (pg_catalog,information_schema);这条命令统计业务 schema 下的表数量。再看有没有大对象和扩展select count(*) from pg_largeobject_metadata; select extname from pg_extension;如果发现大量大对象备份时务必带 -b 参数如果扩展列表里有非内置扩展目标库也要安装对应版本。这一步决定你后面备份命令怎么写。6.2 用 9.1 原配 pg_dump 做逻辑备份迁移备份的命令和第五章的日常备份一样必须用 9.1 自带的 pg_dumpC:\Program Files\PostgreSQL\9.1\bin\pg_dump.exe -h localhost -U postgres -F c -b -v -f D:\backup\app_9_1.dump appdb备份完成后先检查文件大小是否正确再用 pg_restore 的 --list 参数预览内容确认里面包含了预期中的表和索引。6.3 用新版本 psql 恢复与校验在目标新版本实例上创建同名数据库然后用 pg_restore 恢复C:\Program Files\PostgreSQL\16\bin\psql.exe -h localhost -U postgres -c create database appdb; C:\Program Files\PostgreSQL\16\bin\pg_restore.exe -h localhost -U postgres -d appdb -v D:\backup\app_9_1.dump恢复完成后对比表行数和关键数据。先在老库执行C:\Program Files\PostgreSQL\9.1\bin\psql.exe -h localhost -U postgres -d appdb -c select count(*) from main_table;再到新库执行同样语句数字一致才算迁移成功。迁移期间老库不要停确认新库跑通了再切换连接串。我坚持的习惯是老库保留至少一周新库跑几天再决定是否清理老环境这个习惯帮我躲过多次迁移返工。希望帮到你。本文还有配套的精品资源点击获取
