PostgreSQLユーザーがパスワードの変更後にサーバーに接続できない

私はこれを作成した4つの役割で満たしまし
た。GUI（1）を使用してpgAdmin IIIでユーザーのパスワードを変更した後、そのユーザーはそれ以上ログインできなくなります。
pgAdmin III表示エラーメッセージ：

An error has occurred:

Error connecting to the server: FATAL:  password authentication failed for user "sam"
FATAL:  password authentication failed for user "sam"

私のシステム：Ubuntu 12.04上のPostgresql 9.2

これを修正する方法はありますか？

（1）：アカウントpostgresでログインし、ログインロールでユーザーを右クリックし、[定義]タブに移動してパスワードを入力します

このPgAdminバグ（changelog）に噛まれている可能性があります。

2012-11-28 AV 1.16.1日付ピッカーコントロールは、デフォルトで完全なタイムスタンプを返します。これにより、ジョブとロールの有効日付に誤った日付変更が発生する可能性があります。時間の部分は無視してください。

このバグにより、1970年1月1日など、はるか昔のパスワードの有効期限が設定されることが確認されています。この場合、接続しようとしたときのエラーメッセージは、間違ったパスワードを使用した場合と変わりません。

これらの有効期限は次の方法で確認できます。

SELECT usename,valuntil FROM pg_user;

それらが間違っている場合は、次のコマンドでリセットします。

ALTER USER username VALID UNTIL 'infinity';

pgAdminをアップグレードします。

簡単なことは、psqlまたはpgAdminでログインし、

ALTER USER sam WITH PASSWORD 'new_password';

これで、スーパーユーザーアカウントでログインできない場合は、このユーザーのpg_hba.conf設定を変更して設定を再ロードすることで回復できます（サーバーを再起動する必要があることもありますが、理由はわかりません）。

できることは、ユーザーのローカル接続にident（peer in 9.2）メソッド（ユーザーと同じ名前のローカルシステムアカウントを使用できる場合）を使用してログインできるようにする行を追加することです。それは不可能です）「信頼する」に設定します（非常に一時的に！）。信頼を使用する場合は、「ユーザーが主張しているとおりのユーザーであることを信頼してください！」という意味なので、できるだけ早く戻します そのため、この設定を有効にしておくと、すぐに復旧する必要がない場合は危険です。

ログインすると、上記のパスワードをリセットできます。

Windowsバリアントの場合-バージョン9.2のWindows x64インストール用のpgAdminのため、この厄介なバグも経験しました。それは私の生産を麻痺させたままにしました。

フォルダC:\Program Files\PostgreSQL\9.2\dataまたはC:\Program Files (x86)\PostgreSQL\9.**x**\dataに、pg_hba.confテキストファイルがあります。

次の行を見つけます。

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# IPv4 local connections:
host    all             all             127.0.0.1/32            md5
# IPv6 local connections:
host    all             all             ::1/128                 md5

そして、METHOD md5を次のように "trust"に変更します。

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# IPv4 local connections:
host    all             all             127.0.0.1/32            trust
# IPv6 local connections:
host    all             all             ::1/128                 trust

Windows>Runタイプ「services.mscと」と、[Enter]を右PostgreSQLのインスタンスを見つけて、それを再起動します。

これで、DBセキュリティが完全に開放されました。すべての関連ユーザーについて、ユーザーパスワードの有効期限を2099年と変更した後、md5に戻すように警告に注意してください。

まだ試していない場合は、pg_hba.confファイルを確認してください。/var/lib/pgsql/9.3/data/pg_hba.conf（Fedora 20）のような名前になります。見つけるには、「find / -name pg_hba.conf」を使用する必要がある場合があります。

ファイルの下部で、ローカルテスト用に「METHOD」の値を「trust」に変更します（詳細については、postgresのドキュメントを参照してください）。マシンを再起動して、すべてがクリーンに開始され、新しいパラメーターが読み取られることを確認します。

うまくいけば、これはあなたの悩みを癒すでしょう。Fedora 20とPostgreSQL 9.3で私の問題を解決しました。

更新2016-10-14：

Ubuntuでは、必要なファイル名は/etc/postgresql/9.5/main/pg_hba.confです。 ローカルテストの場合のみ、次のように変更します。

...
#
# Database administrative login by Unix domain socket
local   all             postgres                                peer

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
# local   all             all                                     peer
  local   all             all                                     trust
# IPv4 local connections:
# host    all             all             127.0.0.1/32            md5
  host    all             all             127.0.0.1/32            trust

METHODの「信頼」の2行は新しいものです。ユーザー名/パスワードなしで接続できます。

完了したら、次の方法でサーバーを再起動する必要があります。

sudo systemctl restart postgresql 

私はこれと同じ問題を抱えていて、同じ名前の複数のユーザーがいることがわかりました（ケースが異なる）。所有権を統合して削除すると、少なくとも明確でした。接続方法によっては、認証のためにケースが転送されるとは限りませんでした。