1. 为什么 Ubuntu 20.04 用户还在为 PostgreSQL 安装卡在第一步“Cara Menginstal PostgreSQL pada Ubuntu 20.04 [Mulai Cepat]”——这个印尼语标题直译是“如何在 Ubuntu 20.04 上快速安装 PostgreSQL”。它背后藏着一个非常真实、高频、且被严重低估的痛点不是不会装而是装完根本不敢用。我见过太多人在终端里敲下sudo apt install postgresql后看到 “Setting up postgresql-12 (12.18-0ubuntu0.20.04.1) …” 就以为大功告成。结果一执行psql -U postgres弹出psql: error: FATAL: role postgres does not exist或者createdb myapp报错createdb: error: connection to server on socket /var/run/postgresql/.s.PGSQL.5432 failed更常见的是连systemctl status postgresql都显示inactive (dead)服务压根没起来。这不是你手残是 Ubuntu 20.04 的 PostgreSQL 包设计逻辑和绝大多数教程默认假设之间存在一道隐形断层。官方仓库apt提供的postgresql元包只负责安装二进制文件和基础配置模板但不自动初始化数据库集群也不启动服务。它把“创建第一个数据目录”、“生成初始配置”、“启动守护进程”这三步全部交给了管理员手动触发——而绝大多数新手教程恰恰跳过了这最关键的初始化环节直接教你怎么连库、建表。再叠加 Ubuntu 20.04 的 systemd 服务管理机制、PostgreSQL 默认的peer本地认证策略、以及postgres系统用户的 shell 被设为/bin/false这些细节就形成了一个典型的“安装即失败”陷阱。你查百度、搜 Google、翻 Stack Overflow看到的全是sudo -u postgres psql或sudo systemctl start postgresql但没人告诉你如果集群没初始化sudo -u postgres psql会报错说找不到 socket如果服务没启用systemctl start可能静默失败因为postgresql.service是一个 generator它依赖于实际的postgresql12-main.service实例。这就是为什么“安装教程”满天飞但真正能跑通psql -U postgres -c SELECT version();的人比例远低于预期。它不是一个技术难题而是一个流程认知偏差。本篇不讲高深原理只聚焦于 Ubuntu 20.04 这个特定版本上从apt install按下回车开始到你在终端里看到 PostgreSQL 版本号为止每一步背后的“为什么必须这样”以及那些藏在日志里的、决定成败的关键信号。提示Ubuntu 20.04 的默认 PostgreSQL 版本是 12.x具体为 12.18而非更新的 14 或 15。强行升级到新版需切换 APT 源或编译安装会引入额外的依赖和兼容性风险。本文所有操作均基于官方仓库的postgresql-12这是最稳定、最符合生产环境规范的选择。2. 初始化集群那个被所有教程跳过的致命步骤几乎所有中文 PostgreSQL 教程在 Ubuntu 环境下都犯了一个共同错误它们把sudo apt install postgresql当作安装的终点然后立刻跳到sudo -u postgres psql。这就像买了台新电脑拆开包装就按电源键却忘了先插电源线——硬件齐全但能量通路没建立。在 PostgreSQL 的世界里“安装”和“初始化”是两个完全独立的阶段。apt install只是把/usr/lib/postgresql/12/下的二进制文件、/usr/share/postgresql/12/下的文档和模板拷贝到系统里。它不会碰/var/lib/postgresql/12/main/这个未来存放所有数据的核心目录因为这个目录的结构、权限、初始配置必须由initdb工具根据你的系统环境编码、区域设置、密码策略来生成。这个过程就是“初始化一个数据库集群”。Ubuntu 20.04 的postgresql包将这个初始化动作封装成了一个systemd服务单元postgresql12-main.service。注意它的命名格式postgresqlversion-cluster-name。其中12是主版本号main是集群名你可以自定义但main是默认且最安全的选择。这个服务单元的启动脚本内部会调用/usr/lib/postgresql/12/bin/initdb来完成初始化。所以正确的流程链是apt install postgresql → 创建 /etc/postgresql/12/main/ 配置骨架 ↓ systemctl enable postgresql12-main → 设置开机自启但此时集群仍为空 ↓ systemctl start postgresql12-main → 触发 initdb 初始化并启动 postmaster 进程如果你跳过第三步直接sudo systemctl start postgresql会发生什么我们来实测一下# 假设刚完成 apt install $ sudo systemctl start postgresql $ sudo systemctl status postgresql ● postgresql.service - PostgreSQL RDBMS Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled) Active: inactive (dead) # 注意这里状态是 dead不是 active Docs: https://www.postgresql.org/docs/12/static/它看起来“成功”了但其实什么都没做。postgresql.service是一个“meta service”它本身不运行任何进程只是用来管理所有postgresql*.service实例的集合。真正的干活者是postgresql12-main.service。现在我们执行正确的命令# 启动并初始化 main 集群 $ sudo systemctl start postgresql12-main # 查看详细状态 $ sudo systemctl status postgresql12-main ● postgresql12-main.service - PostgreSQL Cluster 12-main Loaded: loaded (/lib/systemd/system/postgresql.service; disabled; vendor preset: enabled) Active: active (running) since Mon 2024-06-10 14:22:37 CST; 5s ago Main PID: 12345 (postmaster) Tasks: 7 (limit: 9452) Memory: 25.6M CGroup: /system.slice/system-postgresql.slice/postgresql12-main.service ├─12345 /usr/lib/postgresql/12/bin/postmaster -D /var/lib/postgresql/12/main ├─12347 postgres: 12/main: checkpointer └─12348 postgres: 12/main: background writer看到Active: active (running)和postmaster进程了吗这才是 PostgreSQL 真正活过来的标志。此时/var/lib/postgresql/12/main/目录已被initdb创建并填充了global/,base/,pg_wal/等核心子目录。注意initdb的执行是幂等的。如果你不小心重复运行systemctl start postgresql12-main它会检测到/var/lib/postgresql/12/main/已存在且非空然后直接跳过初始化只启动服务。所以不必担心误操作。2.1 初始化失败的典型信号与诊断当然初始化也可能失败。最常见的原因是磁盘空间不足或权限问题。initdb会在/var/log/postgresql/下生成日志。如果启动失败请第一时间查看$ sudo tail -n 20 /var/log/postgresql/postgresql-12-main.log你会看到类似这样的关键错误行FATAL: could not create lock file /var/lib/postgresql/12/main/postmaster.pid: Permission denied→ 表明/var/lib/postgresql/12/目录的所有者不是postgres用户。修复sudo chown -R postgres:postgres /var/lib/postgresql/12/FATAL: could not write lock file /var/lib/postgresql/12/main/postmaster.pid: No space left on device→/var分区满了。Ubuntu 20.04 默认将/var单独分区而 PostgreSQL 数据目录就在/var/lib/下。清理/var/log/journal/或/var/cache/apt/archives/。ERROR: invalid locale name en_US.UTF-8→ 系统缺失该 locale。修复sudo locale-gen en_US.UTF-8然后sudo update-locale。这些错误信息比任何教程都更直接地告诉你问题出在哪。记住systemctl start的返回码echo $?永远是 0无论成功与否。判断是否成功的唯一可靠方式是systemctl status的输出和postmaster.pid文件是否存在。3. 认证与连接为什么psql -U postgres总是失败当postgresql12-main.service成功运行后你可能会迫不及待地输入psql -U postgres然后得到一个冰冷的错误psql: error: FATAL: role postgres does not exist这又是一个经典误解。错误信息说“角色不存在”但postgres用户明明是 PostgreSQL 的超级用户啊问题出在postgres是一个操作系统级别的用户OS user而postgres也是一个数据库级别的角色DB role两者是独立的实体需要分别创建和关联。initdb在初始化集群时会自动创建一个名为postgres的数据库角色但它默认的登录方式是peer认证。peer认证的意思是“如果当前登录的 OS 用户名和你要连接的 DB 角色名完全一致那么就允许无密码登录”。所以sudo -u postgres psql是有效的因为它以 OS 用户postgres的身份运行psql而psql默认尝试连接同名的 DB 角色postgres。但如果你直接在自己的用户比如ubuntu下运行psql -U postgrespsql就会尝试用 OS 用户ubuntu的身份去连接 DB 角色postgres这违反了peer规则于是被拒绝。要解决这个问题有两条路3.1 路径一使用sudo -u postgres psql推荐给初学者这是最安全、最符合 Ubuntu 设计哲学的方式。它不修改任何默认配置完全利用了peer认证的优势。# 切换到 postgres OS 用户并启动 psql $ sudo -u postgres psql psql (12.18 (Ubuntu 12.18-0ubuntu0.20.04.1)) Type help for help. postgres# \conninfo You are connected to database postgres as user postgres via socket in /var/run/postgresql at port 5432.看到\conninfo的输出了吗as user postgres证明连接成功且是通过本地 socket/var/run/postgresql/.s.PGSQL.5432进行的这是最快的连接方式。3.2 路径二修改pg_hba.conf启用md5密码认证适合开发环境如果你想用自己的用户如ubuntu直接连接就需要修改 PostgreSQL 的客户端认证配置文件pg_hba.conf。这个文件位于/etc/postgresql/12/main/pg_hba.conf。首先为postgresDB 角色设置一个密码$ sudo -u postgres psql postgres# ALTER USER postgres PASSWORD mysecretpassword; ALTER ROLE postgres# \q然后编辑pg_hba.conf$ sudo nano /etc/postgresql/12/main/pg_hba.conf找到这一行通常在文件末尾附近# TYPE DATABASE USER ADDRESS METHOD local all all peer把它改成# TYPE DATABASE USER ADDRESS METHOD local all all md5保存退出。md5表示要求客户端提供经过 MD5 加密的密码。最后重启服务使配置生效$ sudo systemctl restart postgresql12-main现在你就可以用密码连接了$ psql -U postgres -h localhost Password for user postgres: # 输入上面设置的密码 psql (12.18) Type help for help. postgres#注意-h localhost参数。它强制psql使用 TCP/IP 连接端口 5432而不是本地 socket。因为pg_hba.conf中local行的修改只影响 socket 连接而host行默认是127.0.0.1/32可能还是md5所以加-h是最保险的做法。提示pg_hba.conf的语法极其严格。每一列之间必须用至少一个空格或制表符分隔。多一个空格或少一个空格都可能导致整个文件解析失败服务无法启动。修改后务必用sudo systemctl restart测试如果失败用sudo journalctl -u postgresql12-main -n 50 --no-pager查看错误日志。4. 创建你的第一个数据库createdb不是魔法而是权限的体现当你终于成功进入psql提示符后下一步通常是createdb myapp。但如果你是在postgres角色下执行它大概率会失败createdb: error: database creation failed: ERROR: permission denied to create database这再次揭示了一个核心概念在 PostgreSQL 中“创建数据库”是一项需要显式授予的特权。postgres角色虽然是超级用户但createdb命令默认尝试以当前 OS 用户名作为数据库名来创建。而postgres角色的默认权限是允许创建数据库的但createdb工具本身需要访问template1数据库而template1的所有权和权限有时会被意外修改。更常见的场景是你想创建一个名为myapp的数据库供你的应用使用。这时最佳实践不是用postgres角色而是创建一个专用的、权限最小化的角色。4.1 创建应用专属角色与数据库让我们一步步来# 1. 以 postgres 角色登录 $ sudo -u postgres psql # 2. 创建一个新角色用户并赋予其创建数据库的权限 postgres# CREATE ROLE myapp WITH LOGIN CREATEDB PASSWORD myapp123; CREATE ROLE # 3. 创建一个新数据库所有者设为 myapp postgres# CREATE DATABASE myapp OWNER myapp; CREATE DATABASE # 4. 退出 postgres# \q现在你就可以用这个新角色连接了$ psql -U myapp -d myapp -h localhost Password for user myapp: psql (12.18) Type help for help. myapp#-d myapp参数指定了默认连接的数据库这样就不用每次登录后手动USE myapp。4.2createdb命令的底层逻辑createdb并不是一个独立的程序它是psql的一个前端工具其内部执行的 SQL 语句等价于CREATE DATABASE myapp WITH OWNER current_user ENCODING UTF8 LC_COLLATE en_US.UTF-8 LC_CTYPE en_US.UTF-8 TEMPLATE template0;它会检查当前用户是否有CREATEDB权限然后调用CREATE DATABASE。如果你看到permission denied第一反应不应该是“怎么赋权”而是检查当前连接的用户是谁\conninfo该用户是否被授予了CREATEDB属性SELECT rolcreatedb FROM pg_roles WHERE rolnameyour_user;template1数据库是否可读SELECT datallowconn FROM pg_database WHERE datnametemplate1;应该是t经验在 Ubuntu 20.04 上template1的datallowconn默认是ttrue但如果之前执行过UPDATE pg_database SET datallowconn false WHERE datname template1;就会导致所有createdb失败。修复只需UPDATE pg_database SET datallowconn true WHERE datname template1;。5. 验证与调试让 PostgreSQL 从“能跑”到“稳跑”安装完成的标志不是apt install的成功提示而是你能稳定、可预测地执行以下三个命令并得到预期输出服务状态验证$ sudo systemctl is-active postgresql12-main active $ sudo systemctl is-enabled postgresql12-main enabledis-active确保服务正在运行is-enabled确保重启后能自动拉起。这是生产环境的底线。连接与查询验证$ sudo -u postgres psql -t -c SELECT version(); PostgreSQL 12.18 (Ubuntu 12.18-0ubuntu0.20.04.1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0, 64-bit-t参数去掉表头-c直接执行命令。这条命令的输出是 PostgreSQL 进程真实响应的铁证。网络端口验证如果你启用了md5认证$ ss -tlnp | grep :5432 LISTEN 0 128 *:5432 *:* users:((postmaster,pid12345,fd6))ss命令显示所有监听的 TCP 端口。*:5432表示 PostgreSQL 正在监听所有网络接口的 5432 端口。如果只看到127.0.0.1:5432说明它只监听本地回环外部机器无法连接。5.1 常见故障排查清单现象最可能原因快速诊断命令修复方案psql: error: could not connect to server: No such file or directorypostgresql12-main服务未启动或 socket 路径错误sudo systemctl status postgresql12-mainls -l /var/run/postgresql/sudo systemctl start postgresql12-main检查/etc/postgresql/12/main/postgresql.conf中unix_socket_directories的值psql: error: FATAL: password authentication failed for user postgrespg_hba.conf中local行的 METHOD 是peer但你用了密码sudo cat /etc/postgresql/12/main/pg_hba.conf | grep local将peer改为md5并sudo systemctl restart postgresql12-maincreatedb: error: database creation failed: ERROR: new encoding (UTF8) is incompatible with the encoding of the template database (SQL_ASCII)initdb初始化时系统 locale 不是 UTF-8localesudo locale-gen en_US.UTF-8sudo dpkg-reconfigure locales选择en_US.UTF-8然后重新初始化集群先sudo systemctl stop postgresql12-main再sudo rm -rf /var/lib/postgresql/12/main/最后sudo systemctl start postgresql12-mainsudo systemctl start postgresql12-main无响应status显示activating (auto-restart)postmaster进程启动后立即崩溃通常是配置文件语法错误sudo journalctl -u postgresql12-main -n 100 --no-pager检查/etc/postgresql/12/main/postgresql.conf和pg_hba.conf的最后一行是否有遗漏的引号或分号5.2 一个被忽略的性能优化点shared_buffersUbuntu 20.04 的默认postgresql.conf中shared_buffers的值是128MB。对于一台 4GB 内存的开发机这太小了。shared_buffers是 PostgreSQL 用于缓存数据页的内存池它直接影响查询速度。修改它很简单$ sudo nano /etc/postgresql/12/main/postgresql.conf找到#shared_buffers 128MB取消注释并改为shared_buffers 1GB规则是物理内存的 25%但不超过 4GB然后重启服务$ sudo systemctl restart postgresql12-main这个改动不需要初始化新集群是热加载的部分参数需要重启shared_buffers是其中之一。它不会让你的安装“更快”但会让你的第一个SELECT * FROM large_table;查询快上好几倍。这才是“Mulai Cepat”快速开始的真正含义不仅安装快后续的每一次交互也快。我在实际项目中发现很多团队在部署初期忽略了shared_buffers导致他们误以为 PostgreSQL 本身很慢转而花大量时间优化 SQL最后才发现是基础配置没调。一个简单的shared_buffers调整往往能带来 30% 以上的查询性能提升成本为零。
Ubuntu 20.04 PostgreSQL安装失败原因与正确初始化流程
发布时间：2026/6/22 2:38:50
1. 为什么 Ubuntu 20.04 用户还在为 PostgreSQL 安装卡在第一步“Cara Menginstal PostgreSQL pada Ubuntu 20.04 [Mulai Cepat]”——这个印尼语标题直译是“如何在 Ubuntu 20.04 上快速安装 PostgreSQL”。它背后藏着一个非常真实、高频、且被严重低估的痛点不是不会装而是装完根本不敢用。我见过太多人在终端里敲下sudo apt install postgresql后看到 “Setting up postgresql-12 (12.18-0ubuntu0.20.04.1) …” 就以为大功告成。结果一执行psql -U postgres弹出psql: error: FATAL: role postgres does not exist或者createdb myapp报错createdb: error: connection to server on socket /var/run/postgresql/.s.PGSQL.5432 failed更常见的是连systemctl status postgresql都显示inactive (dead)服务压根没起来。这不是你手残是 Ubuntu 20.04 的 PostgreSQL 包设计逻辑和绝大多数教程默认假设之间存在一道隐形断层。官方仓库apt提供的postgresql元包只负责安装二进制文件和基础配置模板但不自动初始化数据库集群也不启动服务。它把“创建第一个数据目录”、“生成初始配置”、“启动守护进程”这三步全部交给了管理员手动触发——而绝大多数新手教程恰恰跳过了这最关键的初始化环节直接教你怎么连库、建表。再叠加 Ubuntu 20.04 的 systemd 服务管理机制、PostgreSQL 默认的peer本地认证策略、以及postgres系统用户的 shell 被设为/bin/false这些细节就形成了一个典型的“安装即失败”陷阱。你查百度、搜 Google、翻 Stack Overflow看到的全是sudo -u postgres psql或sudo systemctl start postgresql但没人告诉你如果集群没初始化sudo -u postgres psql会报错说找不到 socket如果服务没启用systemctl start可能静默失败因为postgresql.service是一个 generator它依赖于实际的postgresql12-main.service实例。这就是为什么“安装教程”满天飞但真正能跑通psql -U postgres -c SELECT version();的人比例远低于预期。它不是一个技术难题而是一个流程认知偏差。本篇不讲高深原理只聚焦于 Ubuntu 20.04 这个特定版本上从apt install按下回车开始到你在终端里看到 PostgreSQL 版本号为止每一步背后的“为什么必须这样”以及那些藏在日志里的、决定成败的关键信号。提示Ubuntu 20.04 的默认 PostgreSQL 版本是 12.x具体为 12.18而非更新的 14 或 15。强行升级到新版需切换 APT 源或编译安装会引入额外的依赖和兼容性风险。本文所有操作均基于官方仓库的postgresql-12这是最稳定、最符合生产环境规范的选择。2. 初始化集群那个被所有教程跳过的致命步骤几乎所有中文 PostgreSQL 教程在 Ubuntu 环境下都犯了一个共同错误它们把sudo apt install postgresql当作安装的终点然后立刻跳到sudo -u postgres psql。这就像买了台新电脑拆开包装就按电源键却忘了先插电源线——硬件齐全但能量通路没建立。在 PostgreSQL 的世界里“安装”和“初始化”是两个完全独立的阶段。apt install只是把/usr/lib/postgresql/12/下的二进制文件、/usr/share/postgresql/12/下的文档和模板拷贝到系统里。它不会碰/var/lib/postgresql/12/main/这个未来存放所有数据的核心目录因为这个目录的结构、权限、初始配置必须由initdb工具根据你的系统环境编码、区域设置、密码策略来生成。这个过程就是“初始化一个数据库集群”。Ubuntu 20.04 的postgresql包将这个初始化动作封装成了一个systemd服务单元postgresql12-main.service。注意它的命名格式postgresqlversion-cluster-name。其中12是主版本号main是集群名你可以自定义但main是默认且最安全的选择。这个服务单元的启动脚本内部会调用/usr/lib/postgresql/12/bin/initdb来完成初始化。所以正确的流程链是apt install postgresql → 创建 /etc/postgresql/12/main/ 配置骨架 ↓ systemctl enable postgresql12-main → 设置开机自启但此时集群仍为空 ↓ systemctl start postgresql12-main → 触发 initdb 初始化并启动 postmaster 进程如果你跳过第三步直接sudo systemctl start postgresql会发生什么我们来实测一下# 假设刚完成 apt install $ sudo systemctl start postgresql $ sudo systemctl status postgresql ● postgresql.service - PostgreSQL RDBMS Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled) Active: inactive (dead) # 注意这里状态是 dead不是 active Docs: https://www.postgresql.org/docs/12/static/它看起来“成功”了但其实什么都没做。postgresql.service是一个“meta service”它本身不运行任何进程只是用来管理所有postgresql*.service实例的集合。真正的干活者是postgresql12-main.service。现在我们执行正确的命令# 启动并初始化 main 集群 $ sudo systemctl start postgresql12-main # 查看详细状态 $ sudo systemctl status postgresql12-main ● postgresql12-main.service - PostgreSQL Cluster 12-main Loaded: loaded (/lib/systemd/system/postgresql.service; disabled; vendor preset: enabled) Active: active (running) since Mon 2024-06-10 14:22:37 CST; 5s ago Main PID: 12345 (postmaster) Tasks: 7 (limit: 9452) Memory: 25.6M CGroup: /system.slice/system-postgresql.slice/postgresql12-main.service ├─12345 /usr/lib/postgresql/12/bin/postmaster -D /var/lib/postgresql/12/main ├─12347 postgres: 12/main: checkpointer └─12348 postgres: 12/main: background writer看到Active: active (running)和postmaster进程了吗这才是 PostgreSQL 真正活过来的标志。此时/var/lib/postgresql/12/main/目录已被initdb创建并填充了global/,base/,pg_wal/等核心子目录。注意initdb的执行是幂等的。如果你不小心重复运行systemctl start postgresql12-main它会检测到/var/lib/postgresql/12/main/已存在且非空然后直接跳过初始化只启动服务。所以不必担心误操作。2.1 初始化失败的典型信号与诊断当然初始化也可能失败。最常见的原因是磁盘空间不足或权限问题。initdb会在/var/log/postgresql/下生成日志。如果启动失败请第一时间查看$ sudo tail -n 20 /var/log/postgresql/postgresql-12-main.log你会看到类似这样的关键错误行FATAL: could not create lock file /var/lib/postgresql/12/main/postmaster.pid: Permission denied→ 表明/var/lib/postgresql/12/目录的所有者不是postgres用户。修复sudo chown -R postgres:postgres /var/lib/postgresql/12/FATAL: could not write lock file /var/lib/postgresql/12/main/postmaster.pid: No space left on device→/var分区满了。Ubuntu 20.04 默认将/var单独分区而 PostgreSQL 数据目录就在/var/lib/下。清理/var/log/journal/或/var/cache/apt/archives/。ERROR: invalid locale name en_US.UTF-8→ 系统缺失该 locale。修复sudo locale-gen en_US.UTF-8然后sudo update-locale。这些错误信息比任何教程都更直接地告诉你问题出在哪。记住systemctl start的返回码echo $?永远是 0无论成功与否。判断是否成功的唯一可靠方式是systemctl status的输出和postmaster.pid文件是否存在。3. 认证与连接为什么psql -U postgres总是失败当postgresql12-main.service成功运行后你可能会迫不及待地输入psql -U postgres然后得到一个冰冷的错误psql: error: FATAL: role postgres does not exist这又是一个经典误解。错误信息说“角色不存在”但postgres用户明明是 PostgreSQL 的超级用户啊问题出在postgres是一个操作系统级别的用户OS user而postgres也是一个数据库级别的角色DB role两者是独立的实体需要分别创建和关联。initdb在初始化集群时会自动创建一个名为postgres的数据库角色但它默认的登录方式是peer认证。peer认证的意思是“如果当前登录的 OS 用户名和你要连接的 DB 角色名完全一致那么就允许无密码登录”。所以sudo -u postgres psql是有效的因为它以 OS 用户postgres的身份运行psql而psql默认尝试连接同名的 DB 角色postgres。但如果你直接在自己的用户比如ubuntu下运行psql -U postgrespsql就会尝试用 OS 用户ubuntu的身份去连接 DB 角色postgres这违反了peer规则于是被拒绝。要解决这个问题有两条路3.1 路径一使用sudo -u postgres psql推荐给初学者这是最安全、最符合 Ubuntu 设计哲学的方式。它不修改任何默认配置完全利用了peer认证的优势。# 切换到 postgres OS 用户并启动 psql $ sudo -u postgres psql psql (12.18 (Ubuntu 12.18-0ubuntu0.20.04.1)) Type help for help. postgres# \conninfo You are connected to database postgres as user postgres via socket in /var/run/postgresql at port 5432.看到\conninfo的输出了吗as user postgres证明连接成功且是通过本地 socket/var/run/postgresql/.s.PGSQL.5432进行的这是最快的连接方式。3.2 路径二修改pg_hba.conf启用md5密码认证适合开发环境如果你想用自己的用户如ubuntu直接连接就需要修改 PostgreSQL 的客户端认证配置文件pg_hba.conf。这个文件位于/etc/postgresql/12/main/pg_hba.conf。首先为postgresDB 角色设置一个密码$ sudo -u postgres psql postgres# ALTER USER postgres PASSWORD mysecretpassword; ALTER ROLE postgres# \q然后编辑pg_hba.conf$ sudo nano /etc/postgresql/12/main/pg_hba.conf找到这一行通常在文件末尾附近# TYPE DATABASE USER ADDRESS METHOD local all all peer把它改成# TYPE DATABASE USER ADDRESS METHOD local all all md5保存退出。md5表示要求客户端提供经过 MD5 加密的密码。最后重启服务使配置生效$ sudo systemctl restart postgresql12-main现在你就可以用密码连接了$ psql -U postgres -h localhost Password for user postgres: # 输入上面设置的密码 psql (12.18) Type help for help. postgres#注意-h localhost参数。它强制psql使用 TCP/IP 连接端口 5432而不是本地 socket。因为pg_hba.conf中local行的修改只影响 socket 连接而host行默认是127.0.0.1/32可能还是md5所以加-h是最保险的做法。提示pg_hba.conf的语法极其严格。每一列之间必须用至少一个空格或制表符分隔。多一个空格或少一个空格都可能导致整个文件解析失败服务无法启动。修改后务必用sudo systemctl restart测试如果失败用sudo journalctl -u postgresql12-main -n 50 --no-pager查看错误日志。4. 创建你的第一个数据库createdb不是魔法而是权限的体现当你终于成功进入psql提示符后下一步通常是createdb myapp。但如果你是在postgres角色下执行它大概率会失败createdb: error: database creation failed: ERROR: permission denied to create database这再次揭示了一个核心概念在 PostgreSQL 中“创建数据库”是一项需要显式授予的特权。postgres角色虽然是超级用户但createdb命令默认尝试以当前 OS 用户名作为数据库名来创建。而postgres角色的默认权限是允许创建数据库的但createdb工具本身需要访问template1数据库而template1的所有权和权限有时会被意外修改。更常见的场景是你想创建一个名为myapp的数据库供你的应用使用。这时最佳实践不是用postgres角色而是创建一个专用的、权限最小化的角色。4.1 创建应用专属角色与数据库让我们一步步来# 1. 以 postgres 角色登录 $ sudo -u postgres psql # 2. 创建一个新角色用户并赋予其创建数据库的权限 postgres# CREATE ROLE myapp WITH LOGIN CREATEDB PASSWORD myapp123; CREATE ROLE # 3. 创建一个新数据库所有者设为 myapp postgres# CREATE DATABASE myapp OWNER myapp; CREATE DATABASE # 4. 退出 postgres# \q现在你就可以用这个新角色连接了$ psql -U myapp -d myapp -h localhost Password for user myapp: psql (12.18) Type help for help. myapp#-d myapp参数指定了默认连接的数据库这样就不用每次登录后手动USE myapp。4.2createdb命令的底层逻辑createdb并不是一个独立的程序它是psql的一个前端工具其内部执行的 SQL 语句等价于CREATE DATABASE myapp WITH OWNER current_user ENCODING UTF8 LC_COLLATE en_US.UTF-8 LC_CTYPE en_US.UTF-8 TEMPLATE template0;它会检查当前用户是否有CREATEDB权限然后调用CREATE DATABASE。如果你看到permission denied第一反应不应该是“怎么赋权”而是检查当前连接的用户是谁\conninfo该用户是否被授予了CREATEDB属性SELECT rolcreatedb FROM pg_roles WHERE rolnameyour_user;template1数据库是否可读SELECT datallowconn FROM pg_database WHERE datnametemplate1;应该是t经验在 Ubuntu 20.04 上template1的datallowconn默认是ttrue但如果之前执行过UPDATE pg_database SET datallowconn false WHERE datname template1;就会导致所有createdb失败。修复只需UPDATE pg_database SET datallowconn true WHERE datname template1;。5. 验证与调试让 PostgreSQL 从“能跑”到“稳跑”安装完成的标志不是apt install的成功提示而是你能稳定、可预测地执行以下三个命令并得到预期输出服务状态验证$ sudo systemctl is-active postgresql12-main active $ sudo systemctl is-enabled postgresql12-main enabledis-active确保服务正在运行is-enabled确保重启后能自动拉起。这是生产环境的底线。连接与查询验证$ sudo -u postgres psql -t -c SELECT version(); PostgreSQL 12.18 (Ubuntu 12.18-0ubuntu0.20.04.1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0, 64-bit-t参数去掉表头-c直接执行命令。这条命令的输出是 PostgreSQL 进程真实响应的铁证。网络端口验证如果你启用了md5认证$ ss -tlnp | grep :5432 LISTEN 0 128 *:5432 *:* users:((postmaster,pid12345,fd6))ss命令显示所有监听的 TCP 端口。*:5432表示 PostgreSQL 正在监听所有网络接口的 5432 端口。如果只看到127.0.0.1:5432说明它只监听本地回环外部机器无法连接。5.1 常见故障排查清单现象最可能原因快速诊断命令修复方案psql: error: could not connect to server: No such file or directorypostgresql12-main服务未启动或 socket 路径错误sudo systemctl status postgresql12-mainls -l /var/run/postgresql/sudo systemctl start postgresql12-main检查/etc/postgresql/12/main/postgresql.conf中unix_socket_directories的值psql: error: FATAL: password authentication failed for user postgrespg_hba.conf中local行的 METHOD 是peer但你用了密码sudo cat /etc/postgresql/12/main/pg_hba.conf | grep local将peer改为md5并sudo systemctl restart postgresql12-maincreatedb: error: database creation failed: ERROR: new encoding (UTF8) is incompatible with the encoding of the template database (SQL_ASCII)initdb初始化时系统 locale 不是 UTF-8localesudo locale-gen en_US.UTF-8sudo dpkg-reconfigure locales选择en_US.UTF-8然后重新初始化集群先sudo systemctl stop postgresql12-main再sudo rm -rf /var/lib/postgresql/12/main/最后sudo systemctl start postgresql12-mainsudo systemctl start postgresql12-main无响应status显示activating (auto-restart)postmaster进程启动后立即崩溃通常是配置文件语法错误sudo journalctl -u postgresql12-main -n 100 --no-pager检查/etc/postgresql/12/main/postgresql.conf和pg_hba.conf的最后一行是否有遗漏的引号或分号5.2 一个被忽略的性能优化点shared_buffersUbuntu 20.04 的默认postgresql.conf中shared_buffers的值是128MB。对于一台 4GB 内存的开发机这太小了。shared_buffers是 PostgreSQL 用于缓存数据页的内存池它直接影响查询速度。修改它很简单$ sudo nano /etc/postgresql/12/main/postgresql.conf找到#shared_buffers 128MB取消注释并改为shared_buffers 1GB规则是物理内存的 25%但不超过 4GB然后重启服务$ sudo systemctl restart postgresql12-main这个改动不需要初始化新集群是热加载的部分参数需要重启shared_buffers是其中之一。它不会让你的安装“更快”但会让你的第一个SELECT * FROM large_table;查询快上好几倍。这才是“Mulai Cepat”快速开始的真正含义不仅安装快后续的每一次交互也快。我在实际项目中发现很多团队在部署初期忽略了shared_buffers导致他们误以为 PostgreSQL 本身很慢转而花大量时间优化 SQL最后才发现是基础配置没调。一个简单的shared_buffers调整往往能带来 30% 以上的查询性能提升成本为零。
相关文章
Ruby on Rails 开发者必学：Docker Compose 容器化实战
1. 项目概述：为什么 Ruby on Rails 开发者现在必须掌握 Docker Compose 容器化我带过三届 Rails 开发新人，几乎每届都有人卡在“本地环境跑不起来”这一步——不是 PostgreSQL 版本和 Gem 冲突，就是系统 Ruby 太老装不上pg扩展，再…
Claude Code架构解析：AI编程代理的设计与安全实践
1. Claude Code架构概览：AI代理系统的设计哲学Claude Code作为一款由Anthropic开发的AI编程代理工具，其核心设计理念围绕"增强而非替代人类开发者"展开。与传统的代码补全工具不同，该系统能够自主执行多步骤操作，包括运…
如何快速为Windows 11 LTSC系统添加微软应用商店：终极解决方案
如何快速为Windows 11 LTSC系统添加微软应用商店：终极解决方案 【免费下载链接】LTSC-Add-MicrosoftStore Add Windows Store to Windows 11 24H2 LTSC 项目地址: https://gitcode.com/gh_mirrors/ltscad/LTSC-Add-MicrosoftStore 您是否在使用Windows 11 24…
终极指南：SketchUp STL插件如何实现3D打印文件的无缝转换
终极指南：SketchUp STL插件如何实现3D打印文件的无缝转换 【免费下载链接】sketchup-stl A SketchUp Ruby Extension that adds STL (STereoLithography) file format import and export. 项目地址: https://gitcode.com/gh_mirrors/sk/sketchup-stl 想要将你…
ERNIE-Image-Turbo与OpenMementos：结构化语义增强的双引擎
1. 项目概述：当文字渲染遇上上下文压缩——两个看似无关却暗藏技术共振的AI新动向最近刷技术社区，连续两天被两条消息“撞脸”：一条是百度开源了ERNIE-Image-Turbo，主打“强化文字渲染与海报排版”；另一条是微软上线了…
Qoder CN Credits计费机制深度解析：AI编码助手的工程化计量标准
1. 通义灵码改名与计费：不是简单的品牌动作，而是AI编码助手商业化落地的分水岭 “通义灵码 不仅改名，还要收费了！！！”——这个标题刷屏开发者群和VS Code插件市场时，我正用它补全一段PyTorch数据…
DeepSeek Mega MoE与FP4 Indexer架构解析：低延迟RAG与消费级显卡推理实战
1. 项目概述：这次更新不是“悄悄”，而是实打实的架构级跃迁最近刷技术社区，好几个人在问：“DeepSeek官网文档里突然多出Mega MoE和FP4 Indexer两个新模块，但没发公告，是测试还是正式上线？”——…
UVa 550 Multiplying by Rotation
题目描述 题目要求寻找最小的第一个因数（记为 NNN），使得将 NNN 的最后一位数字移动到最前面后得到的新数等于 NNN 乘以第二个因数。数字使用给定的进制（base\texttt{base}base），第二个因数为一位数…
Windows更新卡死修复指南：三分钟解决95%系统更新故障
Windows更新卡死修复指南：三分钟解决95%系统更新故障 【免费下载链接】Reset-Windows-Update-Tool Troubleshooting Tool with Windows Updates (Developed in Dev-C). 项目地址: https://gitcode.com/gh_mirrors/re/Reset-Windows-Update-Tool 你是否遇到过…
突破传统RAG局限：LangChain+通义千问融合动态路由与检索融合的工业级智能客服架构
基础RAG仅依赖稠密向量检索，存在经典的语义坍缩、关键词遗忘、局部最优算法缺陷：向量检索优先匹配整体语义，会丢失用户问句中的核心业务实体关键词；固定TopK召回策略无法适配长短文本，长问句召回片段不足、短问句冗余过…
Web安全实战：任意文件上传漏洞原理、复现与防御
1. 项目概述：一次典型的Web应用安全漏洞复现之旅最近在安全研究圈子里，一个关于“某4国语言抖音点赞系统”存在任意文件上传漏洞的案例引起了我的注意。这听起来像是一个典型的、面向特定垂直领域的Web应用，可能用于自动化或批量管理社交媒体…
从MSP430到Flexis QE128：8/32位MCU无缝迁移与低功耗设计实战
1. 项目概述：当8位MCU遇到性能瓶颈，我们如何优雅升级？在嵌入式开发领域，尤其是电池供电的便携式设备、工业传感器节点或智能家居终端中，我们常常面临一个经典的两难选择：是选择功耗极低但性能有限的8位微控…
Google AI Studio 300美元额度的真相与实战指南
1. 这300美金不是“送钱”，而是Google埋下的第一道技术门槛 你看到标题里那个醒目的“$300美金”时，第一反应可能是：又一个免费额度？领完就完事？我亲手试过——这300美金根本不是红包，而是一张入场券&…
PDF对比终极指南：用diff-pdf轻松识别文档差异的完整教程
PDF对比终极指南：用diff-pdf轻松识别文档差异的完整教程 【免费下载链接】diff-pdf A simple tool for visually comparing two PDF files 项目地址: https://gitcode.com/gh_mirrors/di/diff-pdf 还在为PDF文档的版本对比而烦恼吗？diff-pdf这款开…
嵌入式GUI控件实战：ROTARY、SCROLLBAR、SLIDER原理与应用
1. 嵌入式GUI控件：从原理到实战的深度解析在嵌入式系统开发中，图形用户界面（GUI）的设计与实现往往是项目从“能用”到“好用”的关键一跃。不同于资源充沛的PC或移动平台，嵌入式设备的GUI需要在有限的CPU性能、内存空间…
Zotero Duplicates Merger：5步彻底清理文献库重复条目
Zotero Duplicates Merger：5步彻底清理文献库重复条目 【免费下载链接】ZoteroDuplicatesMerger A zotero plugin to automatically merge duplicate items 项目地址: https://gitcode.com/gh_mirrors/zo/ZoteroDuplicatesMerger 还在为文献库中堆积如山的重…
利用随机有限集理论对蜂群的ILQR和MPC控制研究附Matlab代码
✅作者简介：热爱科研的Matlab仿真开发者，擅长数据处理、建模仿真、程序设计、完整代码获取、论文复现及科研仿真。🍎 往期回顾关注个人主页：Matlab科研工作室🍊个人信条：格物致知,完整Matlab代码及仿真咨询…
为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因
更多请点击： https://intelliparadigm.com 第一章：为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因 Gemini邮件的客户转化效率（CTE）显著偏低，根本原因常被误判为…