PostgreSQL reconsiders its process-based model

I have the impression that this is similar to the adhoc filesystem idea; this seems in principle very advantageous (why employing two layers that do approximately the same thing on top of each other?), but in reality, when implemented (by Oracle), it lead to only a minor improvement (a few % points, AFAIR).

The fundamental problem is that when you're sharing memory, you cannot safely just stop a single process when encountering an unexpected error. You do not know the current state of your shared data, and if it could lead to further corruption. So restarting everything is the only safe choice in this case.

Sure, but the blast radius of corruption is limited to that shared memory, not all the memory of all the processes. You can at least use the fact that a process has crashed to ensure that the corruption doesn't spread.

(This is why it restarts: there is no guarantee that the shared memory is valid, so the other processes are stopped before they attempt to use that potentially invalid memory)

With threads, all memory is shared memory. A single thread that crashes can make other threads data invalid before the detection of the crash.

(Others downthread have pointed out unikernels and I agree with the criticisms)

This proposal is an excellent Phd project for someone like me :-)

It ticks all of the things I like to work on the most[1]:

Will involve writing low-level OS code

Get to hyper-focus on performance

Writing a language parser and executor

Implement scheduler, threads, processes, etc.

Implement the listening protocol in the kernel.

I have to say, though, it might be easier to start off with a rump kernel (netBSD), then add in a specific RAW disk access that bypasses the OS (no, or fewer, syscalls to use it), create a kernel module for accepting a limited type of task and executing that task in-kernel (avoiding a context-swtich on every syscall)[2].

Programs in userspace must have the lowest priority (using starvation-prevention mechanisms to ensure that user input would eventually get processed).

I'd expect a non-insignificant speedup by doing all the work in the kernel.

The way it is now,

userspace requests read() on a socket (context-switch to kernel),

gets data (context-switch to userspace),

parses a query,

requests read on disk (multiple context-switches to kernel for open, stat, etc, multiple switches back to userspace after each call is complete). This latency is probably fairly well mitigated with mmap, though.

logs diagnostic (multiple context-switches to and from kernel)

requests write on client socket (context switch to kernel back and forth until all data is written).

The goal of the DBOS would be to remove almost all the context-switching between userspace and kernel.

[1] My side projects include a bootable (but unfinished) x86 OS, various programming languages, performant (or otherwise) C libraries.

[2] Similar to the way RealTime Linux calls work (caller shares a memory buffer with rt kernel module, populates the buffer and issues a call, kernel only returns when that task is complete). The BPF mechanism works the same. It's the only way to reduce latency to the absolute physical minimum.

PostgreSQL uses a process model. So the article just states that globals work fine for PostgreSQL

> Knizhnik has already done a threads port of PostgreSQL. The global-variable problem, he said, was not that difficult.

I see no big problem based on information from person who did some porting already.