¿Existe alguna nota sobre qué versiones de PostgreSQL son compatibles?
Sería genial tener algo para cada versión de Discourse lanzada, especialmente si una versión de PostgreSQL ya no es compatible.
Postgres viene incluido en el contenedor de Docker para Discourse, por lo que generalmente no requiere intervención. El equipo de Discourse actualiza la versión de Postgres a medida que se lanzan nuevas versiones y estas se prueban adecuadamente. La actualización más reciente fue a la versión 13. Puedes ver los detalles de esa actualización aquí:
3 Me gusta
Bueno, no todo el mundo está usando la base de datos PostgreSQL incluida.
La documentación de instalación actual indica que se requiere la versión 10+ de Postgres:
Dicho esto, las únicas configuraciones oficialmente compatibles son las que utilizan contenedores Docker.
2 Me gusta
Sí, las versiones de PostgreSQL que son “compatibles” (desde la perspectiva de la compilación de Docker, no todas “fuertemente compatibles”) se enumeran en el directorio de plantillas de discourse_docker.
Dicho esto, se recomienda encarecidamente que migres a la versión más reciente de PostgreSQL, actualmente la versión 13, tan pronto como sea posible.
Sin embargo, si estás ejecutando Discourse en un host donde no puedes ejecutar la versión más reciente debido a alguna restricción local en tu organización; el directorio de plantillas de discourse_docker es un buen lugar para investigar.
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
1 me gusta
¿Hay alguna forma de hacer esta actualización de postgresql-client como parte automatizada de una reconstrucción modificando el yaml del contenedor?