Верно, но мы стремимся к простому и прозрачному механизму обновления. Есть преимущества в обоих подходах.
Я бы сказал, делайте то, что вам кажется удобным, и не бойтесь настраивать шаблоны в 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.