맞습니다. 하지만 우리는 단순하고 투명한 업그레이드 메커니즘을 지향하고 있습니다. 양쪽 모두 장점이 있습니다.
필요에 따라 discourse_docker의 템플릿을 커스터마이징하는 것을 두려워하지 마시고, 편안하게 진행하시면 됩니다. 물론 핵심은 먼저 테스트를 수행하고 롤백 계획을 갖추는 것입니다.
저희 호스팅 플랫폼에서는 이러한 기능을 활성화하기 전에 더 많은 테스트와 벤치마킹을 수행할 계획이므로, 설정을 일치시키기 위해 discourse_docker에서도 이를 비활성화했습니다. 비활성화는 엄밀히 말해 필수적이지는 않습니다(내부적으로 discourse_docker의 웹 컨테이너 부분만 사용하므로) 그리고 활성화하는 것에 반대하지 않습니다.
잠재적인 함정 중 하나는 pg_upgrade가 구버전과 신버전의 데이터 디렉터리가 서로 다른 체크섬 설정을 가지고 있으면 작동하지 않는다는 점입니다. 프로세스는 PG15 서버를 종료한 후, 체크섬 없이 PG18로 변환하기 위해 pg_upgrade를 실행하고, pg_checksums를 실행하여 체크섬을 활성화한 다음 PG18을 시작하는 순서여야 합니다. 이는 덤프 및 복원(이번 업그레이드와 같이)을 수행할 때는 문제가 되지 않지만, 주의해야 할 사항입니다.
참고로 데이터 체크섬은 Postgres 9.3부터 사용 가능했지만, 지금까지는 기본적으로 비활성화되어 있었습니다. Postgres 19에서는 온라인으로 이를 활성화/비활성화할 수 있는 기능도 포함될 예정입니다.
현재로서는 아닙니다. Discourse 기능의 대부분은 데이터베이스와 통신하기 위해 Rails PostgreSQL 어댑터를 사용하지만, 백업/복원은 웹 컨테이너의 pg_dump와 psql를 사용합니다. 현재는 이 두 버전을 모두 사용하여 백업/복원을 가능하게 하기 위해 PG15와 PG18 클라이언트를 모두 설치하고 있지만, 미래의 시점에서 PG15를 제거할 것입니다.
주된 동기는 새로운 내장 로케일 제공자(builtin locale provider)로 전환하는 것이었습니다. 저희는 호스팅 플랫폼에서 OS 업그레이드를 추진하고 있으며, glibc와의 결합을 끊고 싶어 합니다.