Why change postgres? Just fork it if you want to change something this fundamental.
PostgreSQL reconsiders its process-based model
221–230 of 377 posts
Re: PostgreSQL reconsiders its process-based model
#222Earlier quoted context omitted.
Is that saying global variables are shared between AppDomains on .NET core then? Scary if so, we have a bunch of .NET framework code we're looking at porting to .NET core in the near future, and I know it relies on AppDomain separation currently. It's not the first framework->Core conversation I've done, but I don't remember changes in AppDomain behaviour causing any issues the first time. As it happens I already kno…
> Is that saying global variables are shared between AppDomains on .NET core then? No, you can't create a second AppDomain at all . AppDomains are dead and buried; you would need to remove all of that from your code in order to migrate to current .NET. The class only remains to serve a couple ancillary functions that don't involve actually creating additional AppDomains.
We're not creating them ourselves, they're created by IIS.
Re: PostgreSQL reconsiders its process-based model
#223For the record, I think this will be a disaster. There is far too much code that will get broken, largely silently, and much of it is not under our control. regards, tom lane (via https://lwn.net/ml/pgsql-hackers/4178104.1685978307@sss.pgh.... ) If Tom Lane says it will be a disaster, I believe it will be a disaster.
Maybe a better option would be finding a team to create nugres, aka a fork for this and other experiments. So that mainline remains stable.
There are several forks of PostgreSQL, in various levels of license, additional features and activity. However, maintaining a fork in addition to a main project is inherently more expensive than maintaining just a single project, so adding features to new major releases of the main project is generally preferred over forking every release into its own, newly named, project. After all, that is what we have major (feature) releases and stabalization windows (beta releases) for.
Re: PostgreSQL reconsiders its process-based model
#224For the record, I think this will be a disaster. There is far too much code that will get broken, largely silently, and much of it is not under our control. regards, tom lane (via https://lwn.net/ml/pgsql-hackers/4178104.1685978307@sss.pgh.... ) If Tom Lane says it will be a disaster, I believe it will be a disaster.
Reminds me of PHP 6...
For those who don't follow PHP closely - that version was an attempted refactor of the string implementation which essentially shut down nearly all work on PHP for a decade, stagnating the language until it became pretty terrible compared to other options. They finally gave up and started work on PHP 7 which uses the (perfectly good) PHP 5 strings.
Ten years of wasted time by the best internal PHP developers crippled the project - I'm amazed it survived at all.
Re: PostgreSQL reconsiders its process-based model
#225For the record, I think this will be a disaster. There is far too much code that will get broken, largely silently, and much of it is not under our control. regards, tom lane (via https://lwn.net/ml/pgsql-hackers/4178104.1685978307@sss.pgh.... ) If Tom Lane says it will be a disaster, I believe it will be a disaster.
He is right. Such rewrites cause a lot of problems if your compiler doesn't help you with avoiding data races. But there is another way.
Indeed, Zig is a nice language for this
Re: PostgreSQL reconsiders its process-based model
#226It would be interesting to have something between threads and processes. I'll call them heavy-threads for sake of discussion. Like light-threads, heavy-threads would share the same process-security-boundary and therefore switching between them would be cheap. No need to flush TLB, I$, D$. Like processes, heavy-threads would have mostly-separate address spaces by default. Similar to forking a process, they could share…
> Like light-threads, heavy-threads would share the same process-security-boundary and therefore switching between them would be cheap. No need to flush TLB, I$, D$.
> Like processes, heavy-threads would have mostly-separate address spaces by default. Similar to forking a process, they could share read-only mappings for shared libraries, code, COW global variables, and explicitly defined shared writable memory regions.
I don't think you realistically can have separate address spaces and not have TLB etc impact. If they're separate address spaces, you need separate TLB entries => lower TLB hit ratio.
Re: PostgreSQL reconsiders its process-based model
#227Earlier quoted context omitted.
Uh. Heikki is definitely not just "some guy". Dude is one of the top contributors to Postgres.
How does that make him immune to having dumb ideas? See, I'm judging the idea on merit. You're just defending your hero who has gone rogue.
Heikki is far from the only "senior" postgres contributor thinking that this is the right direction in the long term.
> You're just defending your hero who has gone rogue.
That doesn't sound like judging an idea on its merit, it sounds like judging a person for something you haven't analyzed yourself.
Re: PostgreSQL reconsiders its process-based model
#228Earlier quoted context omitted.
I've never really been limited by CPU when running postgres (few TB instances). The bottleneck is always IO. Do others have different experience? Plus there's elegance and a feeling of being in control when you know query is associated with specific process which you can deal with and monitor just like any other process. But I'm very much clueless about internals, so this is a question rather than an opinion.
It's not just CPU - memory usage is also higher. In particular, idle connections still consume signficant memory, and this is why PostgreSQL has so much lower connection limits than eg. MySQL. Pooling can help in some cases, but pooling also breaks some important PostgreSQL features (like prepared statements...) since poolers generally can't preserve session state. Other features (eg. notify) are just incompatible wi…
> That said, many of these things are solvable without a full switch to a threaded model (eg. by having pooling built-in and session-state-aware).
The thing is that that's a lot easier with threads. Much of the session state lives in process private memory (prepared statements etc), and it can't be statically sized ahead of time. If you move all that state into dynamically allocated shared memory, you've basically paid all the price for threading already, except you can't use any tooling for threads.
Re: PostgreSQL reconsiders its process-based model
#229Why change postgres? Just fork it if you want to change something this fundamental.
Because it makes it a lot easier to address some of postgres' weaknesses? This is a proposal by long time contributor to postgres, that a number of other long time contributors agree with (and others disagree with!). Why shouldn't have Heikki brought this up for discussion?
Re: PostgreSQL reconsiders its process-based model
#230Earlier quoted context omitted.
No that is what a static in a .c file is for. A plain global can be accessed from other compiled units - agreed with no .h entry it is my=uch more error prone e.g. you don't know the type but the variables name is exposed to other objects
Wouldn't those statics also be slated for removal with this change?
At most they'd be determined to be read only constants that are inlined during constant folding. This includes most integral sized / typed scalar values that fit into registers for the most part, and nothing you've taken the address of either - those remain as static data.