3 ms·

At a very far distance from any real familiarity with Postgres internals, it’s more than a little bit alarming to me that a RDBMS, which already offers strong c

At a very far distance from any real familiarity with Postgres internals, it’s more than a little bit alarming to me that a RDBMS, which already offers strong concurrency guarantees and which already employs multi-process concurrency to do meaningful work, would even have “disaster” uttered in a discussion of a change to its higher level concurrency mechanics. Maybe that’s very naive and I’m very far out of my depth? Is Postgres concurrency really so close to the metal that it should even matter whether it’s operating between processes, threads, or some other shared workload abstraction?

kapilvt 3y ago
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.
- eyelidlessness 3y ago
  > It’s not higher level concurrency mechanics 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?

kapilvt 3y ago

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.

eyelidlessness 3y ago
> It’s not higher level concurrency mechanics 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?