It’s not higher level concurrency mechanics, it’s different, and changing between assumptions of single process concurrency to multi-threaded are generally non trivial for a long established project in c with a vibrant ecosystem (note the evaluation on tcl, perl, and python runtimes). And in general PostgreSQL is a user space application, albeit a database, and generally portable. WRT to metal, this is a few layers removed, but yeah most databases care about their concurrency model, trade offs on x clients, n transactions, y queries, z nodes. In this case the difference between processes and threads causes the concern re switching. In most oss projects this type of change if it happens might take some time. Per my other comment in this thread, pg has a vibrant ecocsystem community both oss, commercial and within org that this will also impact.
That’s what I assumed. I guess what I’m confused (and concerned) about is the types of “disaster” described, which aren’t just about trade offs, but a long tail of potentially undetectable error conditions. I would have expected that to be either a solved problem for Postgres or at least mostly agnostic to the concurrency mechanism. I would figure the change would be questionable for performance and broad computational complexity reasons, not correctness.
Maybe that’s par for the course and my naivety isn’t (just) distance from Postgres internals but the realities of concurrent programming in C?
reply