True, but we’re aiming for a simple transparent upgrade mechanism. There are merits both ways.
I’d say do whatever you’re comfortable with and don’t be afraid to customise the templates in discourse_docker as your needs require. Obviously the key is to test first and have a rollback plan.
On our hosted platform we intend to do more testing and benchmarking before switching these on, and so I disabled them in discourse_docker as well to align the config. It’s not strictly necessary to disable them though (we only use the web container portion of discourse_docker internally) and I wouldn’t be against enabling them.
One potential gotcha is that pg_upgrade will not work if the old and new data directories have different checksum settings. The process would have to be to shut down the PG15 server, run pg_upgrade to convert it to PG18 without checksums, run pg_checksums to enable checksums and then start up PG18. This isn’t a problem when doing a dump and restore (as with this upgrade) but is something to watch out for.
Note that data checksums have been available since Postgres 9.3 but until now have been disabled by default. Postgres 19 will also include the ability to enable/disable them online.
Not at this time, no. Most of the Discourse functionality uses the Rails PostgreSQL adapter to talk to the DB, but backup/restore uses pg_dump and psql in the web container. Right now we’re installing both PG15 and PG18 clients to enable backup/restore using both of these versions, but at some point in the future we’ll remove PG15.
The driving factor was switching to the new builtin locale provider. We are working towards an OS upgrade on our hosted platform and want to break the coupling with glibc.