Errores típicos en PgBouncer (Odoo): “no such user”, “auth failed” y cómo resolverlos rápido
Cuando algo falla entre Odoo → PgBouncer → PostgreSQL, casi siempre aparece uno de estos mensajes:
no such user
password authentication failed
SASL authentication failed
SCRAM authentication requires libpq version 10 or above
authentication method 10 not supported
La clave para arreglarlos sin perder horas es identificar en qué salto falla:
Cliente (Odoo/psql) → PgBouncer (auth de entrada)
PgBouncer → PostgreSQL (auth de salida)
PgBouncer hace ambas autenticaciones, y el auth_file (userlist) se usa tanto para verificar clientes como, si aplica, para autenticarse hacia Postgres. PgBouncer+1
0) Triage en 60 segundos: ¿qué está fallando?
A) Prueba “directa” (sin Odoo) contra PgBouncer
psql "host=127.0.0.1 port=6432 dbname=TU_DB user=odoo"
Si esto falla: el problema está entre cliente → PgBouncer.
Si esto entra, pero Odoo falla: suele ser dbname/dbfilter, credenciales distintas o conexión desde otra IP.
B) Mira el log de PgBouncer (es el juez)
Si puedes, sube temporalmente verbose=1 y confirma que log_pooler_errors=1 está activo (default suele estar encendido). PgBouncer+1
C) Entra a la consola admin de PgBouncer
Conéctate a la “DB” virtual pgbouncer y corre SHOW (en muchos empaquetados/documentación se explica este acceso). EDB
1) Error: no such user
Qué significa de verdad
En la práctica, suele ser una de estas 5 cosas:
El usuario no existe en auth_file y tampoco estás usando auth_user/auth_query.
PgBouncer deja claro que la mayoría de métodos requieren auth_file o auth_user para tener usuarios definidos. PgBouncer+1
auth_file no se está leyendo (permisos/owner/ruta).
Si el proceso de PgBouncer corre como usuario pgbouncer, ese usuario debe poder leer el archivo (caso clásico). Arthur Pemberton
El userlist.txt está mal formateado (comillas, espacios, saltos raros).
El formato esperado es "username" "password|md5...|SCRAM...". PgBouncer
Cambiaste el userlist pero no recargaste PgBouncer.
RELOAD recarga config y también auth_file / auth_hba_file. PgBouncer
Ojo: puede ser “no such database” disfrazado
Por seguridad, PgBouncer puede responder “no such user” aunque el problema real sea que la base pedida no existe (para no filtrar info al cliente). GitHub
Checklist de arreglo
Verifica que el usuario esté en userlist.txt (o que auth_user/auth_query funcione).
Asegura permisos del archivo (mínimo: readable por el usuario del servicio).
Ejecuta RELOAD.
Revisa [databases] en pgbouncer.ini (dbname correcto, wildcard * si lo usas).
2) Error: password authentication failed / auth failed
Causas típicas
Password incorrecta en Odoo (db_password) o en userlist.txt.
Estás usando el usuario equivocado (por ejemplo, Odoo intenta postgres por error).
El usuario existe, pero la contraseña almacenada no coincide con el método/config.
Solución rápida
Prueba con psql contra PgBouncer (descarta Odoo).
Revisa el userlist.txt.
RELOAD. PgBouncer
Confirma que PgBouncer realmente está usando el método que crees (auth_type, o auth_type=hba con auth_hba_file). PgBouncer
3) Error: SASL authentication failed (SCRAM)
Este error es común cuando fuerzas auth_type = scram-sha-256 en PgBouncer o scram-sha-256 en pg_hba.conf.
Las 3 causas más repetidas
A) Cliente viejo (libpq/driver viejo)
PostgreSQL advierte que scram-sha-256 es el método más seguro, pero no está soportado por librerías de cliente antiguas. PostgreSQL
Síntomas relacionados:
SCRAM authentication requires libpq version 10 or above
authentication method 10 not supported
✅ Arreglo: actualiza libpq / driver (psycopg / JDBC / etc.) del lado de Odoo o del cliente.
B) PgBouncer tiene SCRAM, pero tu auth_file no cuadra
PgBouncer permite auth_type = scram-sha-256 y dice que el auth_file debe contener SCRAM secrets o passwords en texto plano. PgBouncer
✅ Arreglo: asegúrate de que el usuario esté en el auth_file con un formato válido.
C) (Muy típica) Pusiste el SCRAM secret en userlist.txt y esperabas que PgBouncer lo use como “password” hacia Postgres
PgBouncer explica que los secretos del auth_file sirven también como password para conexiones salientes si el backend lo requiere. PgBouncer
Pero en SCRAM, el “secret” no siempre es reutilizable como credencial de login; en la práctica muchas instalaciones terminan necesitando el password real (texto plano) para que PgBouncer pueda autenticarse hacia PostgreSQL, o implementar el flujo correcto (client key / estrategias específicas). Stack Overflow+1
✅ Arreglos recomendados:
Opción simple/operable: userlist.txt con password en claro + permisos estrictos.
Opción pro: auth_user + auth_query (centralizar auth en Postgres). PgBouncer documenta cómo funciona auth_user y el query default. PgBouncer
4) Error: auth_type = trust y aun así “login rejected”
Esto confunde a mucha gente.
En PgBouncer, trust significa “no verifico contraseña”, pero el username debe existir en auth_file. PgBouncer+1
✅ Arreglo:
agrega el usuario al auth_file
o usa auth_type=any (solo si sabes exactamente lo que haces; suele ser mala idea en prod).
5) Error: “cambié el userlist y no se aplica”
La receta correcta es:
edita userlist.txt
confirma permisos (que el servicio lo lea)
ejecuta RELOAD
RELOAD recarga config y también auth_file/auth_hba_file. PgBouncer
Si estás en Docker/K8s, revisa que el archivo no esté montado read-only por accidente (caso real reportado). GitHub