Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PostgreSQL reconsiders its process-based model

lwn.net

Post reply on HN
Print view View original

211–220 of 377 posts

Re: PostgreSQL reconsiders its process-based model

#211

Post by tracker1 »

niccl wrote: post #139
zeroimpl wrote: post #131

Earlier quoted context omitted.

However, it's already the case that if a postgres process crashes, the whole cluster gets restarted. I've occasionally seen this message: WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a momen…

yes, but postmaster is still running to roll back the transaction. If you crash a single multi-threaded process, you may lose postmaster as well and then sadness would ensue

You can still have a master control process separate from the client connections.

Re: PostgreSQL reconsiders its process-based model

#212

Post by remexre »

pasc1878 wrote: post #135
cakoose wrote: post #92

Earlier quoted context omitted.

> I think as a straightforward, easily correct transition from 2000 globals, a giant structure isn't an awful idea. Agree. > It's not like the globals were organized before! Using a struct with 2000 fields loses some encapsulation. When a global is defined in a ".c" file (and not exported via a ".h" file), it can only be accessed in that one ".c" file, sort of like a "private" field in a class. Switching to a single…

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?

Re: PostgreSQL reconsiders its process-based model

#213

Post by tracker1 »

wielebny wrote: post #83

Having been using and administering a lot of PostgreSQL servers, I hope they don't lose any stability over this. I've seen (and reported) bugs that caused panics/segfaults in specific psql processes. Not just connections, also processes related to wal writing or replication. The way it's built right now, a child process can be just forced to quit and it does not affect other processes. Hopefully switching into thread…

Most likely, the postmaster will maintain a separate process, much like today with pg, or similar to Firefox or Chrome's control process that can catch the panic'd process, cleanup and restart them. The WAL can be recovered as well if there were broken transactions in flight.

Re: PostgreSQL reconsiders its process-based model

#214

Post by ilyt »

dfox wrote: post #203
ilyt wrote: post #93

Earlier quoted context omitted.

>I've never really been limited by CPU when running postgres (few TB instances). The bottleneck is always IO. Throw a few NVMe drives at it and it might.

Throw a ridiculous amount of RAM at it is more correct assessment. NVMe reads are still an “I/O” and that is slow. And for at least 10 years buying enough RAM to have all off the interesting parts of OLTP psql database either in shared_buffers or in the OS-level buffer cache is completely feasible.

> NVMe reads are still an “I/O” and that is slow

It's orders of magnitude faster than SAS/SATA SSDs and you can throw 10 of them into 1U server. It's nowhere near "slow" and still easy enough to be CPU bottlenecked before you get IO bottlenecked.

But yes, pair of 1TB RAM servers gotta cost you less than half year's worth of developer salary

Re: PostgreSQL reconsiders its process-based model

#215

Post by tracker1 »

timcobb wrote: post #204
BoardsOfCanada wrote: post #85

Earlier quoted context omitted.

From the article: > Tom Lane said: "I think this will be a disaster. There is far too much code that will get broken". He added later that the cost of this change would be "enormous", it would create "more than one security-grade bug", and that the benefits would not justify the cost.

You can think of this as an opportunity to rewrite in Rust.

AfterPostgres

Re: PostgreSQL reconsiders its process-based model

#216

Post by tracker1 »

jasonhansel wrote: post #114

I'm rather surprised that their focus is on improving vertical scalability, rather than on adding more features for scaling Postgres horizontally.

If you're more interested in horizontal scaling, you may want to look into CockroachDB, which has a Postgres compatible protocol, but still quite different. There are a lot more limitations with CDB over Pg though.

With the changes suggested, I'm not sure it's the best idea from where Postgres is... if might be an opportunity to rewrite bits in Rust, but even then, there is a LOT that can go wrong. The use of shared memory is apparently already in place, and the separate process and inter-process communication isn't the most dangerous part... it's the presumption, variables and other contextual bits that are currently process globals that wouldn't be in the "after" version.

The overall surface is just massive... That doesn't even get into plugin compatibility.

Re: PostgreSQL reconsiders its process-based model

#218

Post by electroly »

wizofaus wrote: post #205
SigmundA wrote: post #190

Earlier quoted context omitted.

https://learn.microsoft.com/en-us/dotnet/api/system.appdomai... "On .NET Core, the AppDomain implementation is limited by design and does not provide isolation, unloading, or security boundaries. For .NET Core, there is exactly one AppDomain. Isolation and unloading are provided through AssemblyLoadContext. Security boundaries should be provided by process boundaries and appropriate remoting techniques." AppDomains p…

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.

Re: PostgreSQL reconsiders its process-based model

#219

Post by patmorgan23 »

hans_castorp wrote: post #157
mihaic wrote: post #2

I'm honestly surprised it took them so long to reach this conclusion. > That idea quickly loses its appeal, though, when one considers trying to create and maintain a 2,000-member structure, so the project is unlikely to go this way. As repulsive as this might sound at first, I've seen structures of hundreds of fields work fine if the hierarchy inside them is well organized and they're not just flat. Still, I have no…

> I'm honestly surprised it took them so long to reach this conclusion. Oracle also uses a process model on Linux. At some point (I think starting with 12.x), it can now be configured on Linux to use a threaded model, but the default is still a process-per-connection model. Why does everybody think it's a bad thing in Postgres, but nobody thinks it's a bad thing in Oracle.

Well for one Postgress is open source and widely used. So anyone can pick it up and look at its internals, that's not the case for Oracle DB .

Re: PostgreSQL reconsiders its process-based model

#220

Post by benlivengood »

This is interesting because Google just created AlloyDb[0] which is decidedly multiprocess for performance and switches out the storage layer from a read/write model to write+replicate + read-only model.

The deep dive[1] has some details; the tl;dr: is that the main process only has to output Write Ahead Logs to the durable storage layer which minimizes transaction latency. The log processing service materializes postgres-compatible on-disk blocks that read-only replicas can read from, with a caching layer for block reads which sends cache invalidations from the LPS to read replicas.

I'm not sure if similar benefits could be seen within a single machine; using network DMA or even rDMA to transfer bytes to and from remote machines also avoids TLB invalidation. There are some mentions in the mailing list of waiting for Linux to support shared page mappings between processes as a solution.

I'm not exactly sure I understand the reasoning behind process separation as crash recovery; as far as I understand each connection is responsible for correctness and so if a process crashes there seems to be an assumption that the database can recover and keep working by killing that process but that seems like it risks silent data corruption; perhaps it's equivalently mitigated by separating materialization of blocks from the sync'd WAL in a separate process from the multithreaded connection process producing WAL entries?

[0] https://cloud.google.com/alloydb [1] https://cloud.google.com/blog/products/databases/alloydb-for...

Post reply on HN