pg_ctl start报“could not start server”主因是后台进程启动失败，需结合pg_ctl status和日志诊断；常见原因包括端口占用、权限不足、共享内存限制（如kernel.shmmax过小）、listen_addresses配置不当或crash recovery卡住。
pg_ctl start 报错“could not start server”
绝大多数 PostgreSQL 启动失败，pg_ctl start 会直接退出并打印这句错误，但不告诉你真正原因。它只是个外壳命令，真正启动靠后台进程，出问题时它只负责报“没起来”，不负责诊断。
必须立刻配合 pg_ctl status 和日志一起看——pg_ctl status 返回 “server is not running” 并不能说明没试过启动，只说明当前没存活进程；而 pg_ctl start 的返回码是 1 也不代表配置绝对有误，可能是端口被占、目录权限不对、或共享内存初始化失败。
-
pg_ctl start -D /var/lib/postgresql/data -l /tmp/pg_log.log：强制指定日志路径，绕过默认日志位置不可写的问题 - 如果提示
command not found，先确认pg_ctl在 PATH 中，或用全路径，比如/usr/lib/postgresql/*/bin/pg_ctl - Windows 下注意路径反斜杠和空格，
-D "C:\Program Files\PostgreSQL\data"必须加英文双引号
日志里出现“FATAL: could not create shared memory segment”
这是 Linux 系统级资源限制导致的典型错误，不是 PostgreSQL 配置写错了。PostgreSQL 启动时需要分配大块共享内存（尤其是 shared_buffers 设得高时），而内核参数 kernel.shmmax 或 kernel.shmall 不够就会卡在这一步。
别急着改 postgresql.conf，先查系统限制：
- 运行
sysctl kernel.shmmax，对比你设的shared_buffers（比如2GB≈2147483648字节） - 临时调高：
sudo sysctl -w kernel.shmmax=2147483648 - 永久生效要写进
/etc/sysctl.conf，否则重启后还原 - Docker 容器里默认限制极低，需加
--shm-size=2g启动参数
pg_ctl status 显示“server is running”，但 psql 连不上
进程看似在跑，但实际可能卡在初始化阶段，比如正在恢复 WAL、加载扩展、或等待锁。这时候 pg_ctl status 只检查进程是否存在，不验证服务是否 ready。
更可靠的判断方式是直接连：
-
psql -U postgres -d postgres -c "SELECT 1"—— 如果超时或报connection refused，说明监听没开或端口不对 - 检查
postgresql.conf中listen_addresses是否包含localhost或*，默认常是localhost，Docker 或远程访问时容易漏改 - 检查
port值是否被其他服务占用，用ss -tuln | grep :5432确认 -
pg_isready -U postgres -d postgres比pg_ctl status更准，它真去握手，返回accepting connections才算 OK
日志末尾反复出现“database system was interrupted; last known up at…”
这不是启动失败，而是 PostgreSQL 在做 crash recovery。只要日志继续滚动、没卡住、最终出现 database system is ready to accept connections，就不用干预。
但如果卡在这里很久（尤其 WAL 归档开启时），说明恢复过程受阻：
- 检查
pg_wal/目录下是否有大量未归档的 WAL 文件，归档命令失败会导致 recovery 停摆 - 确认磁盘空间充足：
df -h查pg_wal/所在分区，WAL 写满会直接 halt recovery - 若从备份恢复，确保
recovery.signal文件存在且内容为空，多写一个字符都会让实例拒绝启动 - 不要手动删
pg_wal/里的文件——PG 自己管理，删了可能丢数据
真正难搞的是 recovery 卡在某个 WAL 记录上，这时候日志里会有具体 LSN 和文件名，得比对归档路径里对应文件是否存在、权限是否可读。这种问题没有银弹，只能一环扣一环验。
