問題描述
我安裝了包含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。
參考資料
root@assaf-desktop:/home/assaf# ps axf | grep postgres14338 ? S 0:00 /opt/djangostack-1.3-0/postgresql/bin/postgres -D /opt/djangostack-1.3-0/postgresql/data -p 543214347 ? 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 00127.0.0.1:54320.0.0.0:* LISTEN 14338/postgres tcp6 00::1:5432:::* LISTEN 14338/postgres root@assaf-desktop:/home/assaf#