Exercise 2: Process-Per-Connection vs. Thread-Per-Connection — Possible Solution
====================================================================

POSTGRES: PROCESS-PER-CONNECTION
------------------------------
Per this chapter, "Postgres gives each client connection its own
operating system process — full process isolation, meaning one
connection crashing can't directly take down another connection or
the server as a whole." The trade-off: "processes are heavier to
spawn than threads... which is exactly why connection poolers like
PgBouncer become important at real scale."

Real trade-off: safety and isolation are gained (a bug or crash in
one connection's handling stays contained to that one process), but
at a real resource cost — spawning a new OS process per connection is
more expensive than spawning a thread, which is why high-connection-
count Postgres deployments commonly need an external connection
pooler to avoid that per-connection overhead becoming a bottleneck.

MYSQL: THREAD-PER-CONNECTION
------------------------------
Per this chapter, "MySQL instead handles each client connection as a
thread within a single shared server process — threads are
lighter-weight to create, but a serious bug in one thread's handling
puts the entire mysqld process genuinely at risk, since threads share
memory space far more directly than isolated processes do."

Real trade-off: threads are cheaper to create than processes, so
MySQL can handle connection setup with less per-connection overhead
than Postgres's own default model. But because threads within the
same process share memory space, a severe bug in the code handling
one connection has a more direct path to corrupting or crashing the
entire server process — a risk process isolation specifically avoids.

WHY THIS ISN'T A SIMPLE "ONE IS BETTER" COMPARISON
------------------------------
Per this chapter, this echoes "the same category of decision c3-3
covered when it demonstrated a genuine race condition using pthreads:
shared memory between concurrent execution units buys speed at the
cost of a whole class of bugs that simply can't happen when each
connection is a fully separate process instead." Each model is
optimizing for a genuinely different priority — Postgres for safety/
isolation, MySQL for lighter-weight connection handling — and each
trade-off is real, not a flaw unique to one engine.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains both models using the chapter's own language, states one
concrete trade-off for each (isolation cost vs. shared-memory risk),
and connects the underlying principle to c3-3's own pthreads material
as the chapter itself does.