问题描述
我安装了包含PostgreSQL 8.4的Bitnami Django stack。
当我运行psql -U postgres时，我收到以下错误：
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
PG肯定在运行，pg_hba.conf文件如下所示：
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all md5
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5
是什么赋予了？
pg正在运行的”Proof”：
root@assaf-desktop:/home/assaf# ps axf | grep postgres
14338 ? S 0:00 /opt/djangostack-1.3-0/postgresql/bin/postgres -D /opt/djangostack-1.3-0/postgresql/data -p 5432
14347 ? Ss 0:00 \_ postgres: writer process
14348 ? Ss 0:00 \_ postgres: wal writer process
14349 ? Ss 0:00 \_ postgres: autovacuum launcher process
14350 ? Ss 0:00 \_ postgres: stats collector process
15139 pts/1 S+ 0:00 \_ grep --color=auto postgres
root@assaf-desktop:/home/assaf# netstat -nltp | grep 5432
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 14338/postgres
tcp6 0 0 ::1:5432 :::* LISTEN 14338/postgres
root@assaf-desktop:/home/assaf#
最佳解决方案
此问题来自安装没有版本号的postgres软件包。虽然将安装postgres并且它将是正确的版本，但是设置群集的脚本将无法正确运行;这是一个包装问题。
如果您对postgres感到满意，可以运行一个脚本来创建此集群并运行postgres。但是，有一种更简单的方法。
首先清除旧的postgres安装。目前的问题在于9.1，所以我假设你已经安装了
sudo apt-get remove --purge postgresql-9.1
现在只需重新安装
sudo apt-get install postgresql-9.1
请注意包名称和版本号。 HTH。
次佳解决方案
错误消息是指Unix-domain套接字，因此您需要调整netstat调用以不排除它们。所以在没有选项-t的情况下尝试：
netstat -nlp | grep 5432
我猜想服务器实际上正在侦听套接字/tmp/.s.PGSQL.5432而不是客户端尝试连接的/var/run/postgresql/.s.PGSQL.5432。这是在Debian或Ubuntu上使用hand-compiled或third-party PostgreSQL软件包时的典型问题，因为Unix-domain套接字目录的源默认值为/tmp，但Debian打包将其更改为/var/run/postgresql。
可能的解决方法：
-
使用third-party软件包提供的客户端(致电
/opt/djangostack-1.3-0/postgresql/bin/psql)。可能完全卸载Ubuntu-supplied软件包(由于其他反向依赖性，可能很难)。 -
修复third-party包的套接字目录以与Debian /Ubuntu兼容。
-
使用
-H localhost通过TCP /IP进行连接。 -
使用
-h /tmp或等效的PGHOST设置指向正确的目录。 -
不要使用third-party包。
第三种解决方案
您可以使用psql -U postgres -h localhost强制通过TCP而不是UNIX域套接字进行连接;您的netstat输出显示PostgreSQL服务器正在侦听localhost的端口5432。
您可以通过使用不同的netstat调用来找出PostgrSQL服务器使用的本地UNIX套接字：
netstat -lp --protocol=unix | grep postgres
无论如何，PostgreSQL服务器侦听的接口都在postgresql.conf中配置。
第四种方案
只需创建一个这样的软链接：
ln -s /tmp/.s.PGSQL.5432 /var/run/postgresql/.s.PGSQL.5432
第五种方案
这对我有用：
编辑：postgresql.conf
sudo nano /etc/postgresql/9.3/main/postgresql.conf
启用或添加：
listen_addresses = '*'
重启数据库引擎：
sudo service postgresql restart
此外，您可以检查文件pg_hba.conf
sudo nano /etc/postgresql/9.3/main/pg_hba.conf
并添加您的网络或主机地址：
host all all 192.168.1.0/24 md5
第六种方案
我不得不在Debian Squeeze上编译PostgreSQL 8.1，因为我使用的是Project Open，它基于OpenACS，不会在更新版本的PostgreSQL上运行。
默认的编译配置将unix_socket放在/tmp中，但是依赖于PostgreSQL的Project Open将无法工作，因为它在/var/run/postgresql中查找unix_socket。
postgresql.conf中有一个设置来设置套接字的位置。我的问题是，我可以设置/tmp和psql工作，但不是项目打开，或者我可以设置它为/var/run/postgresql和psql不起作用，但项目打开。
该问题的一个解决方案是为/var/run/postgresql设置套接字，然后根据Peter的建议运行psql，如下所示：
psql -h /var/run/postgresql
这使用本地权限在本地运行。唯一的缺点是它比简单的”psql”打字更多。
有人提出的另一个建议是在两个地点之间建立一个符号链接。这也有效，但是重启后链接消失了。使用-h参数可能更容易，但是，我在/etc/init.d中的PostgreSQL脚本中创建了符号链接。我在”start”部分放置了symbolic link create命令。当然，当我发出一个停止并启动或重启命令时，它会尝试重新创建一个现有的符号链接，但除了警告信息之外，可能没有任何损害。
就我而言，而不是：
ln -s /tmp/.s.PGSQL.5432 /var/run/postgresql/.s.PGSQL.5432
我有
ln -s /var/run/postgresql/.s.PGSQL.5432 /tmp/.s.PGSQL.5432
并在postgresql.conf中明确将unix_socket设置为/var/run/postgresql/.s.PGSQL.5432。
第七种方案
我通过这样做使它工作：
dpkg-reconfigure locales
选择首选语言环境然后运行
pg_createcluster 9.5 main --start
(9.5是我的postgresql版本)
/etc/init.d/postgresql start
然后它的工作原理！
sudo su - postgres
psql
第八种方案
解：
做这个
export LC_ALL="en_US.UTF-8"
还有这个。 (9.3是我目前的PostgreSQL版本。写下你的版本！)
sudo pg_createcluster 9.3 main --start
第九种方案
在我的情况下，它是由我在编辑/etc/postgresql/9.5/main/pg_hba.conf时输入的拼写引起的
我变了：
# Database administrative login by Unix domain socket
local all postgres peer
至：
# Database administrative login by Unix domain socket
local all postgres MD5
但是MD5必须是小写的md5：
# Database administrative login by Unix domain socket
local all postgres md5
第十种方案
我用postgres-9.5服务器无法解决这个问题。经过3天的零进度尝试在这个和其他网站上的每个修复，我决定re-install服务器，并失去了5天的工作量。但是，我确实在新实例上复制了这个问题。这可能会提供一些关于如何解决它的观点，然后再采取我所做的灾难性方法。
首先，禁用postgresql.conf中的所有日志记录设置。这是部分：
# ERROR REPORTING AND LOGGING
评论该部分中的所有内容。然后重启服务。
重新启动时，使用/etc/init.d/postgresql start或restart我发现在重新启动时处于超级用户模式会很有帮助。我打开了一个x-window用于该操作。您可以使用sudo -i建立超级用户模式。
使用以下简单命令验证是否可以访问服务器：psql -l -U postgres
如果这不能解决问题，请考虑以下事项：
在尝试寻找解决方案时，我正在更改许多文件夹的所有权。我知道我可能会尝试将这些文件夹所有权和chmod还原2天。如果您已经搞乱了这些文件夹所有权并且不想完全清除服务器，那么请开始跟踪所有受影响文件夹的设置，以使其恢复到原始状态。您可能希望尝试在另一个系统上进行并行安装，并系统地检查所有文件夹的所有权和设置。单调乏味，但您可以访问您的数据。
获得访问权限后，系统地更改postgresql.conf文件的#ERROR REPORTING AND LOGGING部分中的每个相关行。重启并测试。我发现日志的默认文件夹导致失败。我特意评论了log_directory。系统删除日志的默认文件夹是/var /log /postgresql。