Incident brief
Invalid password
A connection attempt supplied the wrong password for a password-authenticated role. PostgreSQL rejected the connection before it was ever established.
In 10 seconds
- What
- Invalid password
- What triggers it
- Connect with a role that requires password authentication (not trust).
- The fix
- Reconnect with the correct password.
- Proof
- Reproduced on PostgreSQL 16.14 → Connecting with the wrong password, over a network path that genuinely enforces password authentication, was rejected with SQLSTATE 28P01. The correct password, tried right afterward, succeeded.
The fix
What to do right now
The immediate, application-level response to this error.
- Reconnect with the correct password.
- Reset the role's password with ALTER ROLE ... PASSWORD if it's genuinely been lost, rather than working around authentication.
- Never 'fix' this by adding a trust rule to pg_hba.conf — see the counterexample for exactly what that gives up.
-- reconnect with the correct password
SELECT 1 AS connected_successfully;Diagnose
See it live on the server
Run these against the affected instance to confirm the diagnosis before you act.
Standard triage — not specific to this error
These are canonical PostgreSQL system-catalog queries, shown as SQL to run. No sample output is attached because this is general triage, not a captured lab transcript.This SQLSTATE does not have an error-specific live snapshot yet. These are the canonical system-catalog queries you run against the affected server to see the problem in real time — standard triage, not a reproduced transcript.
What is running right now
Active backends, how long each has been running, and what it is waiting on.
SELECT pid,
state,
wait_event_type,
wait_event,
now() - query_start AS running_for,
left(query, 80) AS query
FROM pg_stat_activity
WHERE state <> 'idle'
AND pid <> pg_backend_pid()
ORDER BY running_for DESC NULLS LAST;Who is blocking whom
Turn raw blocking PIDs into the actual queries on both sides of the wait.
SELECT blocked.pid AS blocked_pid,
blocked.query AS blocked_query,
blocking.pid AS blocking_pid,
blocking.query AS blocking_query
FROM pg_stat_activity AS blocked
JOIN LATERAL unnest(pg_blocking_pids(blocked.pid)) AS b(pid) ON true
JOIN pg_stat_activity AS blocking ON blocking.pid = b.pid
WHERE cardinality(pg_blocking_pids(blocked.pid)) > 0;Locks that are still waiting
Every lock a backend has requested but not yet been granted.
SELECT l.pid,
l.locktype,
l.mode,
l.granted,
COALESCE(c.relname, l.transactionid::text) AS object
FROM pg_locks l
LEFT JOIN pg_class c ON c.oid = l.relation
WHERE NOT l.granted
ORDER BY l.pid;Why it happens
What PostgreSQL is telling you
The mechanism behind the error, grounded in the official manual — not paraphrased.
PostgreSQL 16 Documentation — Password Authentication
If no password has been set up for a user, the stored password is null and password authentication will always fail for that user.Read the full section on postgresql.org →
Wrong password
The role postgres requires password authentication on this connection path, and the supplied password did not match — PostgreSQL rejects the connection outright, before any query can run.Correct password, right afterward
The identical connection, with only the password corrected, succeeded immediately — confirming the earlier failure was specifically about the password, not the host, port, role, or database name.Reproduce & verify
A real reproduction over a password-authenticated connection
A literal transcript of SQL run against a live PostgreSQL instance in an isolated lab — the commands below are exactly what was executed.
- 1Connect with a role that requires password authentication (not trust).
- 2Supply the wrong password.
- 3SQLSTATE 28P01 is reported as a FATAL connection error; no session is ever established.
One client, tried twice: first with a wrong password, then with the correct one, both against the same password-authenticated network path.
-- No schema needed: this reproduces at the connection/authentication stage, before any query runs.
SELECT 'no schema required' AS setup_note;psql "host=<db-host> user=postgres password=wrong-password dbname=<app-db>"psql "host=<db-host> user=postgres password=<correct-password> dbname=<app-db>" -c "SELECT 1 AS connected_successfully;"What PostgreSQL actually returned
setup_note
--------------------
no schema required
(1 row)psql: error: connection to server at "<db-host>", port 5432 failed: FATAL: password authentication failed for user "postgres" connected_successfully
-------------------------
1
(1 row)It's easy to assume repeated failed password attempts eventually lock an account, the way many web apps do. This was tested directly: five wrong-password attempts in a row, then the correct password tried immediately after.
Attempt the wrong password five times in a row against the same role, then try the correct password immediately afterward.
Without this
Above: a single wrong password is rejected with SQLSTATE 28P01.
With this, tested
Below: after five wrong attempts in a row, the correct password still works immediately, with no extra delay or lockout.
What Pro unlocks here
- The exact prevention SQL — copy-paste ready
- Raw psql output captured from the Docker lab
- A senior-DBA action list to take it further
- Live monitoring queries to catch it in production
- The deeper audit: fix-that-fails counterexample, GUC before/after, server-log evidence
Related & next steps
Follow the thread
Everything this error touches — jump straight to the sibling error, term, runbook, or parameter.
Verification
- Last verified
- 2026-07-16 (Docker lab, PostgreSQL 16.14)
- Reviewed by
- Verified against PostgreSQL 16.14 in an isolated lab environment
- Audit status
- reviewed