Есть ли где-то примечание о том, какие версии PostgreSQL поддерживаются?
Было бы здорово иметь такую информацию для каждой выпущенной версии Discourse — особенно если какая-то версия PostgreSQL больше не поддерживается.
Postgres входит в состав Docker-контейнера для Discourse, поэтому обычно это происходит автоматически. Команда Discourse обновляет версию Postgres по мере выхода новых релизов, после того как они проходят должное тестирование. Последнее обновление было до версии 13. Подробную информацию об этом обновлении можно найти здесь:
Что ж, не все используют встроенную базу данных PostgreSQL.
В текущей документации по установке указана версия Postgres 10+ как требуемая:
Тем не менее, единственными официально поддерживаемыми конфигурациями являются те, что используют контейнеры Docker.
Да, версии PostgreSQL, которые «поддерживаются» (с точки зрения сборки Docker, хотя не все «полностью поддерживаются»), перечислены в каталоге templates репозитория discourse_docker:
Тем не менее, настоятельно рекомендуется как можно скорее перейти на последнюю версию PostgreSQL, на данный момент это версия 13.
Однако, если вы запускаете Discourse на хосте, где из-за внутренних ограничений вашей организации нельзя использовать последнюю версию, каталог templates в discourse_docker — хорошее место для изучения.
Проверка спустя три года: шаблон Docker по-прежнему указывает PG_MAJOR=13, хотя существуют новые версии PostgreSQL: 14 (2021), 15 (2022) и 16 (2023).
Таким образом, рекомендация всё ещё состоит в использовании версии 13 (которая устареет в 2025 году), а не последней версии PostgreSQL 16 (которая устареет в 2028 году)?
Да, именно так.
У нас уже есть сайты, работающие на версии 15, и обновление с версии 13 планируется на следующий год.
Вопрос: каков текущий статус? Я использую внешний сервер PostgreSQL и хотел бы обновить его с версии 13. PostgreSQL 16 был выпущен 14 сентября 2023 года. Можно ли использовать его с Discourse? Потребуются ли какие-либо шаги миграции для самой базы данных (помимо глобальных шагов миграции на стороне сервера)?
PostgreSQL 13 по-прежнему является официально поддерживаемой версией; последняя версия 13.15 была выпущена в прошлом месяце и также поддерживается.
У нас есть множество сайтов, работающих на версии 15. Это стабильная версия, и мы планируем в конечном итоге выпустить обновление для пользователей с самостоятельным размещением.
Версия 16 пока недостаточно протестирована за пределами машин разработчиков, но если вы любите приключения и хотите попробовать её, чтобы проверить, возникнут ли проблемы, сообщите нам о результатах!
Использует ли Discourse какие-либо нестандартные функции Postgres, из-за которых обновление до новых версий Postgres может не работать при простом дампе и восстановлении?
Поднимаю эту тему, чтобы узнать, есть ли причина пытаться обновиться до PostgreSQL 15 вместо 16 или 17?
И когда мы должны ожидать обновления PostgreSQL?
Привет, ребята! Только что перешёл на AWS RDS PostgreSQL 16.4, и пока всё работает.
У меня версия Discourse 3.4.0.beta3-dev.
Пока не нажимал все кнопки 
, но сама доска, кажется, функционирует, однако…
Я не могу создавать резервные копии из-за следующей ошибки:
[2024-12-13 08:36:07] Убедитесь, что каталог '/var/www/discourse/tmp/backups/default/2024-12-13-083607' существует...
[2024-12-13 08:36:07] Убедитесь, что каталог '/var/www/discourse/public/backups/default' существует...
[2024-12-13 08:36:07] Обновление метаданных...
[2024-12-13 08:36:07] Дамп публичной схемы базы данных...
[2024-12-13 08:36:08] pg_dump: ошибка: версия сервера 16.4; версия pg_dump 13.18 (Debian 13.18-1.pgdg120+1)
[2024-12-13 08:36:08] pg_dump: ошибка: прерывание из-за несовпадения версий сервера
[2024-12-13 08:36:08] ИСКЛЮЧЕНИЕ: сбой pg_dump
Странно то, что я смог импортировать данные с помощью внутренних механизмов:
Что я сделал:
- Настроил БД (пользователь, база данных, права доступа).
- Настроил параметры в app.yml.
- Создал резервную копию внутри Discourse.
- Пересобрал приложение (миграция БД прошла успешно → затем БД оказалась пустой).
- Восстановил резервную копию из контейнера (launcher enter app, discourse enable_restore, discourse restore и т.д.).
- Завершил процесс (всё прошло успешно, и всё работало, пока я не попытался создать новую резервную копию :-)).
Есть ли шансы как-то решить эту проблему?
Привет,
JP
Ребята, сейчас становится интересно.
Я несколько дней не работал и не проверял нашу новую доску компании.
Когда я проверил сегодня, запланированное резервное копирование прошло успешно, но при попытке сделать ручное резервное копирование оно не удалось 
запланированное:
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...
ручное:
[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
хмммм, есть какие-то идеи?
Очень странно 
Я подтверждаю, что обновление до версии 3.4.0.beta3 с использованием внешней базы данных приводит к сбою резервного копирования.
У меня есть два экземпляра 3.4.0.beta3 (тег): 1) с Postgres в Docker (по умолчанию); 2) с внешним Postgres (локальный саморазмещённый).
Первый успешно выполняет резервное копирование как по расписанию, так и вручную:
[2024-12-23 11:11:43] Пометка резервной копии как запущенной...
[2024-12-23 11:11:44] Проверка существования '/var/www/discourse/tmp/backups/default/2024-12-23-111143'...
[2024-12-23 11:11:44] Проверка существования '/var/www/discourse/public/backups/default'...
[2024-12-23 11:11:44] Обновление метаданных...
[2024-12-23 11:11:44] Выгрузка публичной схемы базы данных...
[2024-12-23 11:11:44] pg_dump: последний встроенный OID — 16383
[2024-12-23 11:11:44] pg_dump: чтение расширений
[2024-12-23 11:11:44] pg_dump: идентификация членов расширений
[2024-12-23 11:11:44] pg_dump: чтение схем
...
Второй экземпляр завершается с ошибкой:
[2024-12-21 03:35:21] Пометка резервной копии как запущенной...
[2024-12-21 03:35:21] Проверка существования '/var/www/discourse/tmp/backups/default/2024-12-21-033521'...
[2024-12-21 03:35:21] Проверка существования '/var/www/discourse/public/backups/default'...
[2024-12-21 03:35:21] Обновление метаданных...
[2024-12-21 03:35:21] Выгрузка публичной схемы базы данных...
[2024-12-21 03:35:22] pg_dump: ошибка: версия сервера: 16.6 (Ubuntu 16.6-0ubuntu0.24.04.1); версия pg_dump: 13.18 (Debian 13.18-1.pgdg120+1)
[2024-12-21 03:35:22] pg_dump: ошибка: прерывание из-за несоответствия версий сервера
[2024-12-21 03:35:22] ИСКЛЮЧЕНИЕ: pg_dump завершился с ошибкой
...
Вчера я обновился и подтвердил, что запланированные резервные копии не выполняются из-за несоответствия версий.
Вы можете исправить это, войдя в Docker и установив более новый клиент PostgreSQL.
/var/discourse/launcher enter app
apt update
apt install postgresql-client
Всем привет,
Я перешёл на зашифрованные базы данных PostgreSQL в RDS и вчера делал то же самое (как описывал в предыдущих шагах: создание резервной копии, редактирование app.yml, пересборка и т.д.), и всё работало.
Сегодня я попробовал то же самое с PROD, и теперь получаю эту ошибку
Создание отсутствующих функций в схеме discourse_functions…
Восстановление файла дампа… (это может занять время)
SET
SET
SET
ERROR: unrecognized configuration parameter “transaction_timeout”
EXCEPTION: psql failed: ERROR: unrecognized configuration parameter “transaction_timeout”
Попробовал выполнить это напрямую через DBeaver в базе данных, и там я получаю ту же ошибку (даже для той базы данных, которая вчера работала безупречно).
Резервные копии в обоих случаях были актуальными.
Вы что-то меняли за ночь? 
Спасибо и привет,
WS
Привет,
проверил дамп, создаваемый в файле резервной копии:
В начале он содержит следующее:
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;
Параметр transaction_timeout здесь выглядит странно
так как
transaction_timeout был добавлен в PostgreSQL 17.
Об этом сказано здесь:
https://pgpedia.info/t/transaction_timeout.html
Нужна помощь
Спасибо!
С уважением,
Wurzelseppi
Можно ли сделать это обновление postgresql-client автоматической частью пересборки, изменив yaml-файл контейнера?