L'utente PostgreSQL non può connettersi al server dopo aver modificato la password

Ho incontrato questo con 4 ruoli che ho creato:
Dopo aver cambiato la password per un utente in pgAdmin III usando la GUI (1), quell'utente non può più accedere.
pgAdmin III mostra messaggio di errore:

An error has occurred:

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

Il mio sistema: Postgresql 9.2 su Ubuntu 12.04

Esiste un modo per risolvere questo problema?

(1): accedi con account postgres, fai clic con il pulsante destro dell'utente in Ruoli di accesso, vai alla scheda 'Definizione' e inserisci la password

E 'possibile che sei stato morso da questo bug PgAdmin ( changelog ):

28/11/2012 AV 1.16.1 I controlli di selezione della data restituiscono un timestamp completo per impostazione predefinita, che può causare cambiamenti involontari della data sui lavori e date di validità del ruolo. Ignora la parte temporale.

Questo bug è stato visto per impostare le date di scadenza della password in passato, come 1/1/1970. In questo caso il messaggio di errore quando si tenta di connettersi non è diverso rispetto a una password errata.

Puoi controllare queste date di scadenza con:

SELECT usename,valuntil FROM pg_user;

e se sono sbagliati, ripristinarli con:

ALTER USER username VALID UNTIL 'infinity';

e aggiorna pgAdmin.

La cosa semplice da fare è accedere con psql o pgAdmin e

ALTER USER sam WITH PASSWORD 'new_password';

Ora, se non riesci ad accedere con un account superutente, puoi ripristinare modificando le impostazioni pg_hba.conf per questo utente e ricaricare la configurazione (a volte trovo che ciò richieda il riavvio del server, ma non sono sicuro del perché).

Quello che puoi fare è aggiungere una riga che ti consenta di accedere usando il metodo ident (peer in 9.2) (se puoi usare un account di sistema locale con lo stesso nome dell'utente) per le connessioni locali per l'utente, oppure (se ciò non è possibile) impostato su "trust" (molto temporaneamente!). Se si utilizza la fiducia, arretrare il più presto possibile, poiché ciò significa "fiducia che l'utente è chi afferma!" e di conseguenza questa impostazione è pericolosa da lasciare abilitata al di fuori delle esigenze di recupero immediato.

Una volta effettuato l'accesso è possibile reimpostare la password sopra.

Per la variante di Windows: anch'io ho riscontrato questo brutto bug a causa di pgAdmin per la mia installazione di Windows x64 della versione 9.2. Ha lasciato la mia produzione paralizzata.

Nella cartella C:\Program Files\PostgreSQL\9.2\datao C:\Program Files (x86)\PostgreSQL\9.**x**\data, troverai il file di testo pg_hba.conf .

Trova le seguenti righe:

# 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

e cambia METODO md5 in "fiducia" in questo modo:

# 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

Dal Windows>Runtipo "services.msc" e [invio] trova l'istanza PostgreSQL corretta e riavviala.

La tua sicurezza DB ora è spalancata! Fai attenzione all'avvertimento di riportarlo a md5 dopo aver modificato il tempo di scadenza della password dell'utente per dire l'anno 2099 per tutti gli utenti interessati.

Se non l'hai già provato, rivedi il tuo file pg_hba.conf. Si chiamerà qualcosa come /var/lib/pgsql/9.3/data/pg_hba.conf (Fedora 20); potresti dover usare 'find / -name pg_hba.conf' per localizzarlo.

Nella parte inferiore del file, modifica i valori "METHOD" in "trust" per i test locali (vedi i documenti di Postgres per informazioni complete). Riavviare la macchina per assicurarsi che tutto sia avviato in modo pulito e che vengano letti i nuovi parametri.

Spero che questo possa curare i tuoi guai. Ha risolto i miei problemi su Fedora 20 con PostgreSQL 9.3.

AGGIORNAMENTO 14-10-2016:

Su Ubuntu, il nome file necessario è /etc/postgresql/9.5/main/pg_hba.conf. Solo per i test locali , modificalo in questo modo:

...
#
# 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

Le due linee con "fiducia" METHOD sono nuove. Ti consentono di connetterti senza un nome utente / password.

Al termine, sarà necessario riavviare il server tramite:

sudo systemctl restart postgresql 

Ho appena avuto questo stesso problema e ho scoperto che avevo più utenti con lo stesso nome (casi diversi). Una volta che ho unito la proprietà e rimosso uno, era almeno chiaro. A seconda del metodo di connessione, il caso non è stato necessariamente trasferito per l'autenticazione.