Is there somewhere a note, which postgresql db versions are supported?
Would be great to have something for each released discourse version - especially if a postgresql version is no longer supported.
Postgres is bundled in with the Docker container for Discourse, so this is generally hands-off. The Discourse team upgrades the Postgres version as new releases come out and they are properly tested. The most recent upgrade was to version 13. You can see the details of that upgrade here:
3 Me gusta
Well, not everyone is using the bundled postgres db.
The current install doc lists Postgres 10+ as the required version:
https://github.com/discourse/discourse/blob/master/docs/INSTALL.md
That said, the only officially supported setups are using Docker containers.
2 Me gusta
Yes, the versions of postgres which are “supported” (from a docker build perspective, not all “strongly supported”) are listed in the templates directory of discourse_docker
Having said that, it is highly recommended to move to the latest version of postgres, currently version 13, as soon as you can.
However, if you are running Discourse on a host where you cannot run the latest version because of some local constraint in your organization; the discourse_docker templates directory is a good place to research.
4 Me gusta
Comprobando tres años después: la plantilla de Docker todavía dice PG_MAJOR=13, pero hay nuevas versiones de PostgreSQL: 14 de 2021, 15 de 2022 y 16 de 2023.
Entonces, ¿la recomendación sigue siendo usar la versión 13 (que finalizará su soporte en 2025) en lugar de la última versión de PostgreSQL 16 (que finalizará su soporte en 2028)?
Sí, exacto.
Tenemos algunos sitios ejecutando la versión 15 ya, y deberíamos actualizar desde la 13 el próximo año.
1 me gusta
Pregunta: ¿cuál es el estado actual aquí? Estoy ejecutando una base de datos pg externa y me gustaría actualizar el servidor de base de datos desde la versión 13. PostgreSQL 16 se lanzó el 14 de septiembre de 2023. ¿Se puede usar con Discourse? ¿Se requerirán pasos de migración para la base de datos en sí? (aparte de los pasos de migración globales en el lado del servidor)
PostgreSQL 13 sigue siendo la versión oficialmente compatible, y el mes pasado se lanzó la versión 13.15, que todavía es compatible.
Tenemos un buen número de sitios que ejecutan la versión 15, y esa es una versión que funciona y para la cual planeamos enviar una actualización para los usuarios de autoalojamiento eventualmente.
La versión 16 no ha sido probada ampliamente fuera de las máquinas de los desarrolladores, pero si te sientes aventurero y quieres probarla y ver si algo se rompe, ¡háznos saber cómo te va!
1 me gusta
¿Discourse hace algo fuera de lo común con Postgres que implicaría que las actualizaciones a nuevas versiones de Postgres podrían no funcionar con una simple volcada y restauración?
¿Hay alguna razón para intentar actualizar a PostgreSQL 15 en lugar de 16 o 17?
¿Y cuándo deberíamos esperar actualizar PostgreSQL?
Hola chicos, acabo de mudarme a AWS RDS PostGre 16.4 y parece que está funcionando.
Estoy en la versión de Discourse 3.4.0.beta3-dev.
Aún no he presionado todos los botones 
, pero el panel en sí parece estar funcionando, pero…
No puedo crear copias de seguridad, debido a
[2024-12-13 08:36:07] Asegurándose de que '/var/www/discourse/tmp/backups/default/2024-12-13-083607' existe...
[2024-12-13 08:36:07] Asegurándose de que '/var/www/discourse/public/backups/default' existe...
[2024-12-13 08:36:07] Actualizando metadatos...
[2024-12-13 08:36:07] Volcando el esquema público de la base de datos...
[2024-12-13 08:36:08] pg_dump: error: versión del servidor: 16.4; versión de pg_dump: 13.18 (Debian 13.18-1.pgdg120+1)
[2024-12-13 08:36:08] pg_dump: error: abortando debido a incompatibilidad de versión del servidor
[2024-12-13 08:36:08] EXCEPCIÓN: pg_dump falló
Lo extraño es que pude importar los datos con mecanismos internos:
Lo que hice:
- Configuré la base de datos (usuario, base de datos, permisos).
- Configuré cosas en app.yml.
- Creé una copia de seguridad desde dentro de Discourse.
- Reconstruí la aplicación (la migración de la base de datos fue exitosa → la base de datos está vacía entonces).
- Restauré la copia de seguridad desde dentro del contenedor (launcher enter app, discourse enable_restore, discourse restore …).
- Terminado (todo exitoso, y todo parecía estar funcionando, hasta que intenté crear una nueva copia de seguridad ).
¿Hay alguna forma de abordar esto de alguna manera?
Saludos,
JP
1 me gusta
Ok chicos, ahora se pone interesante.
No estuve trabajando durante unos días y no revisé nuestro nuevo panel de control de la empresa.
Cuando lo revisé hoy, la copia de seguridad programada funcionó, luego intenté hacer la copia de seguridad manual de nuevo, y eso falló 
programada:
Dumping the public schema of the database...
[2024-12-04 06:02:16] pg_dump: last built-in OID is 16383
[2024-12-04 06:02:16] pg_dump: reading extensions
[2024-12-04 06:02:16] pg_dump: identifying extension members
[2024-12-04 06:02:16] pg_dump: reading schemas
[2024-12-04 06:02:16] pg_dump: reading user-defined tables
[2024-12-04 06:02:16] pg_dump: reading user-defined functions
[2024-12-04 06:02:16] pg_dump: reading user-defined types
......
pg_dump: dumping contents of table "public.themes"
[2024-12-04 06:02:19] pg_dump: processing data for table "public.top_topics"
[2024-12-04 06:02:19] pg_dump: dumping contents of table "public.top_topics"
[2024-12-04 06:02:19] Finalizing backup...
[2024-12-04 06:02:19] Creating archive: scp-talk-2024-12-04-060216-v20241127034553.tar.gz
[2024-12-04 06:02:19] Making sure archive does not already exist...
[2024-12-04 06:02:19] Creating empty archive...
[2024-12-04 06:02:19] Archiving data dump...
[2024-12-04 06:02:19] Archiving uploads...
[2024-12-04 06:02:19] Removing tmp '/var/www/discourse/tmp/backups/default/2024-12-04-060216' directory...
[2024-12-04 06:02:19] Gzipping archive, this may take a while...
[2024-12-04 06:02:19] Executing the after_create_hook for the backup...
[2024-12-04 06:02:19] Deleting old backups...
[2024-12-04 06:02:19] Cleaning stuff up...
[2024-12-04 06:02:19] Removing '.tar' leftovers...
[2024-12-04 06:02:19] Marking backup as finished...
[2024-12-04 06:02:19] Refreshing disk stats...
[2024-12-04 06:02:19] Notifying '<me>' of the end of the backup...
manual:
[2024-12-16 10:03:54] '<me>' has started the backup!
[2024-12-16 10:03:54] Marking backup as running...
[2024-12-16 10:03:54] Making sure '/var/www/discourse/tmp/backups/default/2024-12-16-100354' exists...
[2024-12-16 10:03:54] Making sure '/var/www/discourse/public/backups/default' exists...
[2024-12-16 10:03:54] Updating metadata...
[2024-12-16 10:03:54] Dumping the public schema of the database...
[2024-12-16 10:03:54] pg_dump: error: server version: 16.4; pg_dump version: 13.18 (Debian 13.18-1.pgdg120+1)
[2024-12-16 10:03:54] pg_dump: error: aborting because of server version mismatch
[2024-12-16 10:03:54] EXCEPTION: pg_dump failed
hmmmmm, ¿alguna idea?
Muy extraño 
Confirmo que la actualización a 3.4.0.beta3 con una base de datos externa provoca fallos en la copia de seguridad.
Tengo dos instancias 3.4.0.beta3 (tag): 1) con Postgres-en-Docker (predeterminado); 2) con Postgres externo (autoalojado localmente).
La primera puede realizar copias de seguridad tanto programadas como manuales:
[2024-12-23 11:11:43] Marcando la copia de seguridad como en ejecución...
[2024-12-23 11:11:44] Asegurándose de que '/var/www/discourse/tmp/backups/default/2024-12-23-111143' existe...
[2024-12-23 11:11:44] Asegurándose de que '/var/www/discourse/public/backups/default' existe...
[2024-12-23 11:11:44] Actualizando metadatos...
[2024-12-23 11:11:44] Volcando el esquema público de la base de datos...
[2024-12-23 11:11:44] pg_dump: el último OID incorporado es 16383
[2024-12-23 11:11:44] pg_dump: leyendo extensiones
[2024-12-23 11:11:44] pg_dump: identificando miembros de la extensión
[2024-12-23 11:11:44] pg_dump: leyendo esquemas
...
La segunda falla:
[2024-12-21 03:35:21] Marcando la copia de seguridad como en ejecución...
[2024-12-21 03:35:21] Asegurándose de que '/var/www/discourse/tmp/backups/default/2024-12-21-033521' existe...
[2024-12-21 03:35:21] Asegurándose de que '/var/www/discourse/public/backups/default' existe...
[2024-12-21 03:35:21] Actualizando metadatos...
[2024-12-21 03:35:21] Volcando el esquema público de la base de datos...
[2024-12-21 03:35:22] pg_dump: error: versión del servidor: 16.6 (Ubuntu 16.6-0ubuntu0.24.04.1); versión de pg_dump: 13.18 (Debian 13.18-1.pgdg120+1)
[2024-12-21 03:35:22] pg_dump: error: abortando debido a discrepancia en la versión del servidor
[2024-12-21 03:35:22] EXCEPCIÓN: pg_dump falló
...
2 Me gusta
Me actualicé ayer y confirmo que las copias de seguridad programadas fallan debido a una discrepancia de versión.
Puedes solucionarlo entrando en docker e instalando un cliente postgresql más nuevo.
/var/discourse/launcher enter app
apt update
apt install postgresql-client
2 Me gusta
Hola chicos,
He cambiado a bases de datos PostGre cifradas en RDS, y estaba haciendo lo mismo ayer (como describí en pasos anteriores (hacer copia de seguridad, editar app.yml, reconstruir, …) y funcionó ayer.
Hoy lo he intentado con PROD y ahora me sale este error
Creando funciones faltantes en el esquema discourse_functions…
Restaurando archivo de volcado… (esto puede tardar un tiempo)
SET
SET
SET
ERROR: parámetro de configuración no reconocido “transaction_timeout”
EXCEPTION: psql falló: ERROR: parámetro de configuración no reconocido “transaction_timeout”
Lo he intentado con DBeaver directamente en la base de datos, y ahí me sale el mismo error (incluso para esa base de datos, que funcionó perfectamente ayer).
Las copias de seguridad estaban actualizadas en ambos casos.
¿Habéis cambiado algo durante la noche? 
Gracias y saludos,
WS
Hola,
revisé la copia de seguridad que se está realizando en el archivo de copia de seguridad:
Incluye esto en la parte superior
SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET transaction_timeout = 0;
SET client_encoding = ‘UTF8’;
SET standard_conforming_strings = on;
El parámetro transaction_timeout es extraño aquí
ya que
transaction_timeout se añadió en PostgreSQL 17.
indicado aquí:
https://pgpedia.info/t/transaction_timeout.html
Necesito ayuda
¡Gracias!
Saludos,
Wurzelseppi
¿Hay alguna forma de hacer esta actualización de postgresql-client como parte automatizada de una reconstrucción modificando el yaml del contenedor?