Just a FYI for people-- don’t try this upgrade during prime time. The 2.6.0b2 upgrade has been running on our server for well over 40 minutes when normally it takes just a couple of minutes, usually over before you check back. I was concerned it was broken, but logging into postgres I can see a hug…

A note on the extended Docker Manager and/or rebuild via SSH time has been added to the release notes.

Just pulled out a stop watch and tested a rebuild (site with around 1M posts only) from 2.6.0b1 to b2; and from start to finish, it took 170 seconds. [IMG_9870] [Screen Shot 2020-08-21 at 6.34.31 PM] This is my second rebuild today, going from b1 to b2 and it seems very fine with no noticeable …

I also don’t use the docker manager and prefer to use the rebuild from command line. It’s better this way to see the log in case anything goes wrong. I also think it’s faster.

Yes, seems it’s mostly a problem on forums with a lot of posts.

I (foolishly) upgraded via the web console, so I didn’t have an up to date log the whole time. Last time I make that mistake.

I had a large site that repeatedly failed to bootstrap. It’s a 2-container install, so the old container continued to run while the bootstrap was migrating. I eventually solved the problem by turning on SKIP_POST_DEPLOYMENT_MIGRATIONS=1 for the bootstrap and then running the migrations after the new…

[image] pfaffman: If there were a way to have ./launcher pass SKIP_POST_DEPLOYMENT_MIGRATIONS=1 into things without requiring an edit to the app.yml it’d make things less fiddly for the editor-challenged. Good idea, I went and implemented that: https://github.com/discourse/discourse_docker/p…

That is fantastic news! (Two other projects got in the way today and somehow my multisite instance is no longer working and playing well with S3. :crying_cat_face:) Thanks very much.

Is there a technical reason why post-upgrade DB changes need to be blocking by default? Is there any way to change that behavior so future upgrades get the site back up quickly and then run the post-upgrade stuff in the background? IMO anything essential for the upgraded application to function lik…

We started our rebuild from the command line seven hours ago! and is still going… It’s still here: [image] Any ideas? Edit: meanwhile I’ve killed the process to have the site live again for our users. But there has to be a better way to do this update.

2.6.0b2 upgrade VERY slow

Support Self-hosting

riking (Kane York) August 21, 2020, 11:39pm 20

Good idea, I went and implemented that:

https://github.com/discourse/discourse_docker/pull/481

Topic		Replies	Views
2.6.0 beta 3 update failed on disk and/or memory space Self-hosting server-resources	28	2726	September 26, 2020
An upgrade knocked my site offline; how long until it's restored? Self-hosting	15	447	July 10, 2025
Upgrade failed spectacularily Support	25	908	February 10, 2025
Problem rebuilding because of slow database shutdown Self-hosting	26	1346	April 25, 2023
PostgreSQL 18 update for self-hosters Announcements	54	995	August 11, 2026

2.6.0b2 upgrade VERY slow

Related topics