ПРИМЕЧАНИЕ: Неясна причина, но обновление до PostgreSQL 18 отключает встроенные контрольные суммы данных. Контрольные суммы данных PostgreSQL являются функцией по умолчанию, и их отключение кажется очень необычным.
PR для отключения отключения проверки контрольных сумм данных (включено по умолчанию): Do not disable PostgreSQL 18 data checksums - Pull Request #1105 - discourse/discourse_docker - GitHub
И это лучше, чем иметь 20 ГБ свободного места на один час в году, ха-ха
Возможно, это должен быть рекомендуемый подход, чтобы спасать деревья и воду. 
Просто чтобы уточнить, я не использую PostgreSQL, предоставляемый Discourse, и сам Discourse пока не требует PG18, верно? Значит, мне (пока) не обязательно обновляться до PG18.
Верное замечание. Но другая причина в том, что LTS-релизы выходят раз в пару лет, поэтому не такая уж плохая идея сделать это одновременно.
У вас definitely есть время. Они довольно быстро после обновления настояли на… э-э, каком-то релизе из-за какой-то необходимой функции, но вы, скорее всего, можете подождать до года. Я слежу за репозиторием discourse_docker. В какой-то момент они начнут говорить об удалении поддержки PG15; это не особенно шумно и является простым способом следить за обновлениями внутренних компонентов.
2 лайка
На моей установке Pi 5 всё работало нормально, два пересборки и готово.
7 лайков
Кстати, у нас есть какие-нибудь бенчмарки?
Это могло бы подтолкнуть других скорее последовать нашим смелым шагам.
Мой бесплатный ИИ для веб-поиска говорит мне:
Для типичного Rails-приложения переход с PostgreSQL 15 на 18 может обеспечить ~10–25% более высокую производительность запросов без изменений в коде, а до 40% — для определённых паттернов запросов, если использовать новые возможности индексации и планировщика.
Если это правда, то это довольно значительное улучшение! 
7 лайков
Просто хочу подтвердить, что на нашем self-hosted экземпляре всё прошло безупречно. Спасибо за это обновление и держите нас в курсе.
5 лайков
Верно, но мы стремимся к простому и прозрачному механизму обновления. Есть преимущества в обоих подходах.
Я бы сказал, делайте то, что вам кажется удобным, и не бойтесь настраивать шаблоны в discourse_docker по мере необходимости. Очевидно, главное — сначала протестировать и иметь план отката.
На нашей хостинговой платформе мы планируем провести больше тестов и бенчмарков перед их включением, поэтому я также отключил их в discourse_docker, чтобы согласовать конфигурацию. Однако отключать их не обязательно (внутри мы используем только часть discourse_docker для веб-контейнера), и я не против их включения.
Один потенциальный подвох заключается в том, что pg_upgrade не будет работать, если в старых и новых каталогах данных будут разные настройки контрольных сумм. Процесс должен выглядеть так: остановить сервер PG15, запустить pg_upgrade для конвертации в PG18 без контрольных сумм, запустить pg_checksums для включения контрольных сумм, а затем запустить PG18. Это не является проблемой при использовании дампа и восстановления (как в этом обновлении), но об этом стоит помнить.
Обратите внимание, что контрольные суммы данных доступны с версии Postgres 9.3, но до сих пор были отключены по умолчанию. В Postgres 19 также появится возможность включать/отключать их на лету.
На данный момент — нет. Большинство функций Discourse использует адаптер Rails для PostgreSQL для взаимодействия с БД, но для резервного копирования/восстановления используются pg_dump и psql в веб-контейнере. Сейчас мы устанавливаем клиенты как PG15, так и PG18, чтобы обеспечить резервное копирование/восстановление для обеих этих версий, но в какой-то момент в будущем мы удалим PG15.
Главным фактором было переключение на новый встроенный поставщик локалей. Мы работаем над обновлением ОС на нашей хостинговой платформе и хотим разорвать зависимость от glibc.
3 лайка
Я управляю своим PostgreSQL независимо от контейнера. Какой рекомендуемый хэш Git мне следует переключить для pg18?
1 лайк
e7f1201 добавил клиент PG18 в веб-образ для обеспечения совместимости резервных копий. Если вы не используете ни один из компонентов сервера Postgres в discourse_docker, то это самая ранняя ревизия, которую следует использовать для PG18.
1 лайк
Я говорил об обновлении, которое было одно или два назад.
Согласен. Моя мысль заключалась лишь в том, что возможность восстановления старой резервной копии PostgreSQL на более новой версии ничуть не менее поддерживается. Механизм обновления на месте работает удивительно хорошо для подавляющего большинства пользователей, но когда что-то идёт не так, трудно понять, что делать (во многом потому, что это происходит крайне редко).
2 лайка
Если это кому-то поможет, на те моменты, когда SSH-консоль замирает, и когда начинает накатывать холодный пот от паники…
Я запустил это в другом терминале, чтобы следить за прогрессом:
watch -n 10 'df -h /; echo; du -sh /var/discourse/shared/standalone/postgres_data* 2>/dev/null'Это обновляется каждые 10 секунд и помогает сохранить рассудок
Миграция 35 ГБ заняла около 10 минут.
8 лайков
Обновление прошло у меня без проблем с установкой по умолчанию. Конечно, перед этим я сделал и скачал резервную копию на случай, если что-то пойдет не так 
3 лайка
Отлично. Я бы добавил туда free -h — нехватка памяти довольно распространенная проблема.
Единственный недостаток watch или даже top заключается в том, что они постоянно обновляются, поэтому вы можете что-то пропустить. Если у вас закончится место и обновление не удастся, через несколько секунд запись будет потеряна. Поэтому я обычно запускаю что-то вроде цикла while — например, так:
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 лайка
Могу сообщить об успехе… в половине моей многосайтовой установки. Основной сайт был перенесен как ожидалось, но вторичный сайт выглядел как новая установка. К счастью, восстановить резервную копию не так уж сложно. У меня есть другой сервер, который я использую для клиентов, и я думаю, что создам новый Droplet и восстановлю сайты из резервных копий, чтобы выполнить это обновление. Это одна из рисков использования нестандартной установки, я полагаю.
1 лайк
Был ли ваш контейнер с данными стандартным контейнером с данными? Я задумался, перемещается ли только одна база данных или все базы данных в кластере. Похоже, вы ответили на мой вопрос!
Что я делал, так это вручную перемещал каждую базу данных из старого кластера в новый, затем вручную редактировал discourse.conf, чтобы указать на новую базу данных, а затем выполнял пересборку, чтобы направить весь мультисайтовый контейнер на новый кластер (на другом компьютере или порту).
1 лайк
Да, был. Конечно, я не могу утверждать, что не допустил никаких ошибок в своей настройке. 
Я планировал использовать rsync для синхронизации данных PostgreSQL, чтобы выполнить там обновление qn и точно проверить, перемещает ли процесс только базу данных Discourse или весь кластер, но, похоже, вы уже ответили на мой вопрос, и это станет ясно, если я посмотрю в код.
2 лайка
У меня есть два вопроса:
- Мы подключили дополнительный блок хранилища к тестовому серверу. Однако обновление PostgreSQL не проходит, поскольку проверка свободного места выполняется только для основного диска. Можно ли как-то обойти эту проверку?
- Для нашего продакшн-сервера мы используем Google Cloud SQL. Есть ли что-то, что нам нужно знать перед обновлением через Google Cloud?