4 ms·
I have always found it odd how some databases conflate network connections with threads (or processes) of execution. If Postgres has an ideal number of concurre
by arielweisberg 13y ago
I have always found it odd how some databases conflate network connections with threads (or processes) of execution. If Postgres has an ideal number of concurrent workers it should instantiate that many and multiplex requests from various connections across them which has several benefits including allowing you to preemptively shed requests you know you won't get to in time and do other scheduling and QoS stuff.
I get it from a historical perspective where it would have been needless complexity to implement something else.
On an unrelated note it's pretty amazing what threads get conflated with in general.
- wulczer 13y agoOne of the important reasons Postgres connections are serviced by a separate process is that if that process segfaults, you only disconnect other connections (because if might have tainted shared memory when it died), but the main database process keeps running and you can reconnect immediately.
- adamtj 13y agoNot quite. If a backend segfaults, postgres will detect it and immediately terminate all connections and exit. When it restarts, it will enter recovery mode. It does this because a segfaulted backend may have corrupted shared memory. The only way to fix that to restart in recovery mode and replay the WAL.
- gaius 13y agoIt is no odder than Unix conflating your shell with a process, really. You connect, run some commands within a context that's "yours", then it's all cleaned up when you go.