Problem rebuilding because of slow database shutdown

Thanks-- so ./launcher rebuild web_only (or rebuild data) instead of ./launcher rebuild app, and I’d need to closely read updates to see when postgres or redis is updated to manually update them as well. And the main advantage over standalone is rebuilds don’t need to wait for the database to shutdown and then start back up, rolling-back transactions if it was killed.

But with Falco’s latest changes, the DB should never be killed unless it takes >10min to shutdown, which it certainly won’t unless we get a metric f-ton more users. So the updates won’t fail due to that problem, and the main impact is just to make updates take a couple minutes longer.

My read is that ultimately the change adds a bunch of complexity and mental overhead for really very little gain. Please correct me if I’m wrong, that isn’t meant to be sarcastic/etc.

Just as a bit of background, the change would have to offer substantial benefits to be worth that overhead because this is all an unpaid favor by me (one now stretching out 15 years+, but nonetheless), not my job. Real YMMV situation there.

Right.

Lots of people share that opinion, which I continue to find surprising. Postgres upgrades come less than once a year, and there is usually no penalty for delaying them for months after the initial change. Having a 2-container setup means that you can more easily delay upgrading postgres than if you have a single container, which seems like another advantage to me.

With the 2-container setup, you can

 ./launcher bootstrap web_only && ./launcher destroy web_only; ./launcher start web_only

and have (typically) less than a minute of downtime.

But you don’t want to, so don’t.

3 Likes

Delaying postgres upgrades has historically meant a simple config yaml change, unless you guys plan to stop supporting that. We can handle a couple extra minutes of downtime for upgrades, and to my eyes that’s less risk than relying on one person (that’s me!) to properly maintain a less standard, more complex configuration.

From my perspective, the main win of two containers is the reduced downtime - like you, I think, I’m OK with 20-30mins of downtime every couple of months. But it’s easy to see that for some forums that’s too much.

1 Like

Totally. Even if we were talking 90 minutes standalone downtime versus 5 minutes separated I still probably wouldn’t think the change was worthwhile, although I’d probably do upgrades late at night rather than conveniently in the middle of the day if it took that long. We aren’t a realtime stock trading platform, we’re a free forum about videogames.

With the 2-container setup, it means that you don’t even need to know to make that simple change. And there would be zero chance that you’d start an upgrade and then learn that you had already started upgrading postgres.

But I’ve spent close to 35 years living in a shell.

And now I have a dashboard that automates those command-line upgrades (and handles postgres upgrades and a bunch of other stuff).

But don’t fix what ain’t broken, and I understand that moving stuff around and potentially breaking stuff is scary.

2 Likes

I started on slackware myself, I just don’t see forum maintenance as a fun project and want it to go away so I can continue to beat my head against the wall trying to get google home to integrate with home assistant (or whatever else takes my fancy that week).

1 Like