NOTA: No estoy seguro de la razón, pero la actualización a PostgreSQL 18 desactiva las sumas de verificación de datos nativas. Las sumas de verificación de datos de PostgreSQL son una función predeterminada y parece muy inusual desactivarlas.
PR para no deshabilitar las comprobaciones de datos (habilitadas por defecto): Do not disable PostgreSQL 18 data checksums - Pull Request #1105 - discourse/discourse_docker - GitHub
Y es mejor que tener que liberar 20 GB durante la única hora que lo necesitas en todo un año, jaja
Quizás esta debería ser la recomendación oficial para salvar árboles y agua. 
Solo para confirmar, no estoy usando PostgreSQL proporcionado por Discourse y Discourse en sí aún no requiere PG18, ¿correcto? Así que no estoy (aún) obligado a actualizar a PG18.
Buena observación. Pero el otro punto es que las versiones LTS se publican cada par de años, así que no está de más hacerlo al mismo tiempo.
Tienes mucho tiempo. Insistieron en… eh, en una versión bastante rápido después de la actualización debido a alguna función que era obligatoria, pero probablemente puedas esperar hasta un año. Sigo el repositorio de discourse_docker. En algún momento empezarán a hablar de eliminar el soporte para PG15; no es algo muy ruidoso y es una forma fácil de estar al tanto de las actualizaciones de componentes internos.
2 Me gusta
Funcionó perfectamente en mi instalación de Pi 5, dos reconstrucciones y listo.
7 Me gusta
¿Tenemos algún benchmark por cierto?
Esto podría animar a otros a seguir nuestras audaces huellas antes.
Mi IA de búsqueda web gratuita me dice:
Para una aplicación Rails típica, pasar de PostgreSQL 15 a 18 puede ofrecer ~10–25 % más de rendimiento en las consultas sin cambios en el código, y hasta un 40 % en patrones de consulta específicos si aprovechas las nuevas funciones de indexación y planificación.
Si es cierto, ¡es una mejora bastante notable! 
7 Me gusta
Solo para confirmar que todo salió a la perfección en nuestra instancia autoalojada. Gracias por esta actualización y manténgannos informados.
5 Me gusta
Es cierto, pero nuestro objetivo es un mecanismo de actualización sencillo y transparente. Ambas opciones tienen sus ventajas.
Diría que hagas lo que te resulte más cómodo y no tengas miedo de personalizar las plantillas en discourse_docker según tus necesidades. Obviamente, lo fundamental es probar primero y tener un plan de reversión.
En nuestra plataforma alojada, tenemos la intención de realizar más pruebas y benchmarks antes de activarlas, por lo que también las deshabilité en discourse_docker para alinear la configuración. Sin embargo, no es estrictamente necesario deshabilitarlas (internamente solo usamos la parte del contenedor web de discourse_docker) y no me opondría a activarlas.
Un posible problema es que pg_upgrade no funcionará si los directorios de datos antiguo y nuevo tienen configuraciones de comprobación de integridad diferentes. El proceso debería consistir en detener el servidor PG15, ejecutar pg_upgrade para convertirlo a PG18 sin comprobaciones de integridad, ejecutar pg_checksums para habilitar las comprobaciones y luego iniciar PG18. Esto no es un problema al hacer una volcado y restauración (como en esta actualización), pero es algo en lo que hay que tener cuidado.
Ten en cuenta que las comprobaciones de integridad de datos están disponibles desde Postgres 9.3, pero hasta ahora se han mantenido deshabilitadas por defecto. Postgres 19 también incluirá la capacidad de habilitarlas o deshabilitarlas en línea.
No, por el momento no. La mayor parte de la funcionalidad de Discourse utiliza el adaptador PostgreSQL de Rails para comunicarse con la base de datos, pero la copia de seguridad y restauración usa pg_dump y psql en el contenedor web. Por ahora, estamos instalando los clientes de PG15 y PG18 para permitir copias de seguridad y restauraciones con ambas versiones, pero en algún momento del futuro eliminaremos PG15.
El factor determinante fue el cambio al nuevo proveedor de localizaciones integrado. Estamos trabajando en una actualización del sistema operativo en nuestra plataforma alojada y queremos romper la dependencia con glibc.
3 Me gusta
Gestiono mi instancia de PostgreSQL de forma independiente al contenedor. ¿Cuál es el hash de Git recomendado al que debería cambiar para usar pg18?
1 me gusta
e7f1201 agregó el cliente PG18 a la imagen web para compatibilidad con copias de seguridad. Si no estás utilizando ninguno de los componentes del servidor Postgres de discourse_docker, esa es la revisión más antigua que deberías usar para PG18.
1 me gusta
Me refería a una o dos actualizaciones atrás.
De acuerdo. Mi punto era simplemente que no es menos válido poder restaurar una copia de seguridad de PostgreSQL antigua en una versión más reciente. El mecanismo de actualización in situ funciona de maravilla para la gran mayoría de las personas, pero cuando algo sale mal, es difícil saber qué hacer (principalmente porque ocurre tan raramente).
2 Me gusta
Por si le sirve a alguien, para esos momentos en los que la consola SSH se queda estática y empiezan a aparecer los sudores fríos del pánico…
Ejecuté esto en otra terminal para vigilar el progreso:
watch -n 10 'df -h /; echo; du -sh /var/discourse/shared/standalone/postgres_data* 2>/dev/null'Que te actualiza cada 10 segundos y te mantiene cuerdo
Mi migración de 35 GB tardó unos 10 minutos.
8 Me gusta
La actualización se realizó sin problemas con la instalación estándar. Por supuesto, antes hice una copia de seguridad y la descargué por si algo salía mal 
3 Me gusta
Genial. Yo añadiría un free -h a eso, ya que la falta de memoria es un problema bastante común.
El único inconveniente de usar watch o incluso top es que se actualizan constantemente, por lo que podrías perderte algo. Si se agota algún recurso y la actualización falla, unos segundos después habrás perdido el registro. Así que tiendo a ejecutar algo más parecido a un bucle while, quizás así:
while true; do date; echo; free -h; echo; df -h /; echo; sh -c 'du -sh /var/discourse/shared/standalone/postgres_data* 2>/dev/null'; sleep 10; echo; done
4 Me gusta
Puedo informar de un éxito . . . en la mitad de mi configuración multisitio. El sitio predeterminado se migró como se esperaba, pero el sitio secundario parecía una instalación nueva. Afortunadamente, no es difícil restaurar una copia de seguridad. Tengo otro servidor que uso para clientes y estoy pensando en crear una nueva Droplet y restaurar los sitios desde copias de seguridad para realizar esta actualización. Supongo que este es uno de los riesgos de usar una instalación no estándar.
1 me gusta
¿Tu contenedor de datos era un contenedor de datos estándar? Me preguntaba si movería solo una base de datos o todas las del clúster. ¡Parece que has respondido a mi pregunta!
Lo que he estado haciendo es mover manualmente cada base de datos desde el clúster antiguo al nuevo, luego editar manualmente discourse.conf para que apunte a la nueva base de datos y, a continuación, realizar una reconstrucción para que todo el contenedor multisite apunte al nuevo clúster (en una máquina diferente o en otro puerto).
1 me gusta
Sí. Por supuesto, no puedo afirmar que no haya cometido ningún error en mi configuración. 
Había planeado hacer rsync de mis datos de postgres para ejecutar la actualización qn allí y verificar con certeza si el proceso movía solo la base de datos de Discourse o todo el clúster, pero parece que has respondido a mi pregunta y eso quedará claro si reviso el código.
2 Me gusta
Tengo dos preguntas aquí:
- Hemos montado un bloque de almacenamiento adicional en el servidor de pruebas. Pero la actualización de PostgreSQL falla porque la comprobación de espacio solo revisa el disco principal. ¿Hay alguna forma de omitir la comprobación de espacio?
- Para nuestro sitio de producción, usamos Google Cloud SQL. ¿Hay algo que debamos saber antes de realizar la actualización a través de Google Cloud?