No señor, no hay problema. Gracias por la información.
En mi caso, fue porque tenía scram-sha-256 y no trust como el mecanismo de autenticación.
Porque scram-sha-256 requiere un usuario físico.
Probablemente puedas solucionar eso creando un mapa de usuarios en pg_ident.conf, pero no estoy seguro de cómo.
Si por “usuario físico” te refieres a “usuario del sistema Unix”, entonces no, scram-sha-256 no requiere que dicho usuario esté configurado en el sistema. El método peer requiere un usuario del sistema, y trust es simplemente una mala idea en general cuando se utiliza un servidor de base de datos remoto.
1 me gusta
¿Tendremos que incluir lo siguiente además del proceso existente?
CREATE EXTENSION vector;
¿ya que veo esta extensión en la plantilla postgres de discourse_docker?
Eso es utilizado por el plugin principal de Discourse AI, por lo que lo necesitarás si lo estás usando.
No recuerdo haber habilitado ese plugin. De hecho, acabo de comprobar que está deshabilitado. Pero recientemente, cuando reconstruí la imagen, cuando el último commit fue más allá de este commit - GitHub - discourse/discourse at 0eab7daea450e1d7e416c46a23aaaf95687d4855, rake db:migrate comenzó a fallar. Cuando usé el commit justo antes del anterior para arrancar, continuó funcionando.
Ahora que he habilitado esta extensión, los commits posteriores a este funcionan sin problemas.
1 me gusta
Pero ahora el plugin de IA está en el núcleo, por lo que necesita la extensión independientemente de si usa el plugin de IA (o se las arregla para eliminarlo explícitamente), ¿verdad?
1 me gusta
Es cierto, ya que las migraciones se ejecutan independientemente de que el plugin esté habilitado.
2 Me gusta