News for hackers. Stuff that matters.
Re:The growing pains of database architecture by agf on Wednesday June 07, 2023 @10:08AM (#36226973)
I've been in situations like this where the cost of killing active queries was lower than the cost of pausing traffic (and having it potentially back up or time out) for the extra time it would take for those queries to finish.

Just because you can wait for them to finish, doesn't mean it's better to when you look at the cutover as a whole.

Re:The growing pains of database architecture by nikita2206 on Wednesday June 07, 2023 @10:22AM (#36227139)
Ah indeed, this is a trade off.
Re:The growing pains of database architecture by ye-olde-sysrq on Wednesday June 07, 2023 @10:58AM (#36227619)
Also, if you asked me to pick my poison: things get partially available / degraded for a long period of time, or there's a blip of full unavailability during a cutover, I'd pick the latter 9 times out of 10. I find people are pretty good about writing code to deal with "does it work y/n" but people are often a lot less good about "does it nominally work but is going so slow it will never complete / other things will time out in unexpected orders before this finishes / etc". Some of the worst incidents I've seen were "partial" outages that spanned a long time period until the right thing could be drained/kicked/whatever.
Re:The growing pains of database architecture by dmattia on Wednesday June 07, 2023 @11:36AM (#36228220)
This took me a long time to accept in my career, but I do believe you've summarized this in a way that rings true for me as well.
Re:The growing pains of database architecture by sharadov on Wednesday June 07, 2023 @05:36PM (#36233921)
Take that one big hit vs death by a thousand cuts!