The upgrade script will check for free space and only proceed if safe to do so.
There are two steps during the process where disk space may become critical. If you were to bypass the free space check this is where you could run into trouble:
- When running pg_dump to extract the data from the old DB (2x DB storage required at this point).
- When running pg_restore to insert the data back into the new DB (3x DB storage required at this point).
To recover from this state you would need to remove /shared/postgres_dump and /shared/postgres_data_new.
Note that at the end of the upgrade we remove the temporary pg_dump files but retain your pre-upgrade DB data at /shared/postgres_data_old Just In Case. Once you’re happy everything is working you’ll probably want to remove that directory to reclaim disk space.
I’ve tested taking a Discourse backup on a PG15 site and restoring it onto a PG18 site. It worked for me, but be aware that it is not an officially supported method. Test thoroughly on something non-production first and make sure you have a rollback path!
I would recommend studying the process used by the upgrade script. If you have special storage requirements you should be able to adapt it to your needs. Again, test first:
This is now in discourse_docker, yes. If you pull main or run ./launcher rebuild app you will get it.
Switching discourse_docker off the main branch will help prevent accidental upgrades if you want to postpone it.