PostgreSQL reconsiders its process-based model

Re:PostgreSQL reconsiders its process-based model by anarazel on Tuesday June 20, 2023 @12:44AM (#36399812)

What makes you think that it will require that many changes? There will be some widespread mechanical changes (which can be verified to be complete with a bit of low level work, like a script using objdump/nm to look for non-TLS mutable variables) and some areas changing more heavily (e.g. connection establishment, crash detection, signal handling, minor details of the locking code). But large portions of the code won't need to change. Note that we/postgres already shares a lot of state across processes.

[ Parent | on HN ]

Re:PostgreSQL reconsiders its process-based model by giraffe_lady on Tuesday June 20, 2023 @05:34AM (#36401652)

I'm not the person you asked and I don't have any particular knowledge of postgres internals.

Experience with other systems has taught me that in a system that's been in active use and development for decades, entanglement will be deep, subtle, and pervasive. If this isn't true of postgres then it's an absolute freak anomaly of a codebase. It is in other ways, so it's possible.

But the article mentions there being thousands of global variables. And Tom Lane himself says he considers it untenable for exactly this reason. That's a very good reason to think that it will require that many changes imo.

[ Parent | on HN ]

Re:PostgreSQL reconsiders its process-based model by h0l0cube on Tuesday June 20, 2023 @08:57AM (#36403326)

> that many changes

The 'that many changes' in question is a complete rewrite. Many changes across many files, yes, but nothing even approaching a rewrite.

> I don't have any particular knowledge of postgres

Judging by their bio, the person you're replying to does.

[ Parent | on HN ]