PostgreSQL启动提示the database system is starting up排查方案

这个报错的本质是数据库正处于实例恢复阶段，正常场景下WAL回放完成就会自动进入可用状态，启动超过10分钟未完成，针对Windows免安装运行的场景，按优先级从高到低排查以下问题：

• 优先查pgdata目录权限：这是Windows免安装版最高发的问题。启动postgres进程所用的Windows账号，必须对初始化生成的pgdata文件夹拥有完全控制权限。常见踩坑场景包括把pgdata放在了C:\Program Files等系统UAC管控目录、跨机器拷贝pgdata文件夹时丢失了NTFS权限、用普通账号启动但pgdata是之前用管理员账号初始化生成的。修复方式很简单：右键pgdata文件夹打开「属性-安全」，给当前运行PostgreSQL的账号勾选完全控制权限，结束所有残留postgres进程后重启即可。
• 检查恢复是否真的卡住，别盲目重启：如果故障机之前运行PostgreSQL时出现过强杀进程、意外断电、系统蓝屏，数据库下次启动必须回放未落盘的WAL日志，恢复时长和异常退出前的写入量正相关，大批量写入后异常退出的场景恢复十几分钟到半小时都属于正常范围。你直接打开pgdata下的pg_log目录，看最新的日志文件，如果日志里持续打印redo进度相关记录，说明恢复在正常推进，等着就行——反复重启进程会导致恢复每次从头开始，反而越等越久。
• 清理残留进程和锁文件：如果之前启动的postgres进程没有正常退出，残留进程会占用5432端口、锁定pgdata下的文件，新启动的进程会卡在锁等待阶段，一直显示启动中。打开任务管理器找到所有postgres.exe进程强制结束，然后删除pgdata根目录下的postmaster.pid锁文件，再重新执行启动命令，注意不要同时启动多个postgres进程指向同一个pgdata目录。
• 核对配置参数的适配性：如果你是把正常运行那台机器的配置文件直接拷贝到故障机，重点检查几个和本机环境绑定的参数：data_directory是不是写了另一台机器的绝对路径、listen_addresses是不是绑定了故障机不存在的IP、shared_buffers是不是设置得过大超过故障机当前可用内存——Windows环境下免安装版PostgreSQL的shared_buffers建议设置为物理内存的1/4，最大不要超过2G，参数设置过大导致内存申请失败时，恢复流程会一直重试没有明确报错。
• 排查数据目录完整性问题：如果pg_log里出现块读取失败、无效页、WAL日志损坏相关的报错，说明你跨机器拷贝pgdata的时候，源端数据库没有正常停止，拷贝的文件处于不一致状态，导致恢复无法推进。迁移pgdata目录必须先正常停止源端数据库服务，再完整拷贝整个文件夹，不要在数据库运行时直接复制数据目录。

所有PostgreSQL启动阶段的问题都会在pg_log目录下的日志文件里打印明确的错误信息或进度记录，排查时优先看日志，不要仅根据客户端返回的启动中报错盲目操作。

内容的提问来源于stack exchange，提问作者Abimanyu