摘要：
出现这个问题，主要原因在于postgresql的配置的认证权限不对。postgresql的配置权限的文件在/var/lib/pgsql/data/pg_hba... 出现这个问题，主要原因在于postgresql的配置的认证权限不对。
postgresql的配置权限的文件在
/var/lib/pgsql/data/pg_hba.conf
里面主要是关于认证权限的配置
PostgreSQL 支持下面这些身份验证方式：
trustpasswordpeeridentGSSAPISSPIKerberosLDAPRADIUScertificatePAM
我们先详细讲解一下 PostgreSQL 中四种最常见的身份验证方式。
trust 身份验证
当使用 trust 身份验证方式时， PostgreSQL 会认为凡是能连接到该数据库服务器的，都是可信任的，可以随意访问数据库，而不管他们用什么数据库用户名来访问。这里边包含了如下几个意思：
基于密码的身份验证
基于密码的身份验证方式包括 md5 和 password。这两种方式非常相似，唯一的区别在于传输密码的时候前者是md5加密的，后者是明文的。同样的：
ident 身份验证
ident 方式通过 Identification 协议，从 ident 服务器获得客户端操作系统用户名，然后把操作系统用户名作为数据库用户名。该方式只能用于TCP/IP连接。当 ident 被用于本地(非TCP/IP)链接时， 实际上采用的是 peer 方式。
RFC 1413 文档描述了 Identification 协议。几乎所有的Unix类操作系统都提供了 ident 服务器（openSUSE可以安装 oidentd或者 pidentd），这些 ident 服务器默认监听 TCP 113 端口。ident 服务器的基本功能就是回答类似“哪个用户建立了从你的X端口出来然后连入我的Y端口的连接？”的问题。由于 PostgreSQL 知道物理链接的 X 端口和 Y端口，它就可以询问链接客户端所在主机上的 ident 服务器，从而可以知道这条链接是哪个操作系统用户建立的。
这个流程的缺点是它依赖于客户端的完整性：如果客户端机器不可信，攻击者可以在113端口运行任意程序并返回任意用户名。因而这种身份验证方式只适合于封闭网络，而且该网络中的所有客户端机器都必须严格控制，数据库管理员和系统管理员必须紧密联系。换句话说，你必须信任运行 ident 服务器的机器。同时你还必须注意，RFC 1413协议明确说明了，Identification 协议的设计意图并不是为了身份验证和访问控制。
一些 ident 服务器提供了非标准选项，会导致返回加密了的用户名，而加密时使用的密钥只有 ident 服务器的管理员知道。这些 ident 服务器要和 PostgreSQL 协同工作，一定不能使用这些选项，因为 PostgreSQL 无法解密返回的字符串，无从知道真实用户名。
同样的：
peer 身份验证
peer 身份验证方式通过客户端操作系统内核来获取用户名，并作为数据库用户名来进行登录。该方式只能应用在本地连接上。peer 身份验证方式只能在那些提供了getpeereid()函数，SO_PEERCRED socket参数或者类似机制的操作系统中使用。当前包括 Linux,大多数 BSD系统比如 Mac OS X 和 Solaris。
在Centos中安装的postgresql，默认的本地认证方式是ident，也就是peer。数据库的用户名必须有对应的操作系统用户名，因此如果一个叫Jedi的操作系统用户，要以postgres用户身份登录，就会出现“认证错误”。大家可以把认证方式改为trust或者password，就可以了。
再多说一句，操作系统的用户与postgresql中的用户是两码事，可以有不同的密码。如果是用的password的认证方式，那么你用postgres登录操作系统后，还需要再次输入postgresql的密码，才能进入数据库。
