Exercise 3: A Unit With Only After=postgresql.service — A Real Scenario Where It Starts Without It — Possible Solution
====================================================================

A real scenario: PostgreSQL is not installed on this particular
server at all, or its own unit is disabled/masked and genuinely never
attempted to start during this boot -- perhaps this is a web-tier
server in a setup where the database actually runs on a completely
separate machine, and postgresql.service was never configured to run
locally here in the first place.

Explanation:

Per the chapter's own core point, After=postgresql.service on its own
means only "IF postgresql.service is going to start anyway, for
whatever reason, start after it" -- it explicitly does NOT, by itself,
cause postgresql.service to be started as a side effect. If nothing
else on this system independently Wants= or Requires=
postgresql.service (which is exactly the case if PostgreSQL isn't
even installed, or its unit is disabled), then postgresql.service
simply never starts during this boot at all -- there's no unmet
dependency to block on, because no dependency was ever declared, only
an ordering preference. The unit with only After=postgresql.service
would then start normally, with no error and no indication that
PostgreSQL was ever expected -- exactly the chapter's own described
"silently wrong behavior on a system where networking [or, here, a
database] happens to come up slowly or not at all," now applied to
this exercise's own database scenario.

WHY THIS WORKS AS AN ANSWER
------------------------------
This constructs a genuinely plausible real scenario (PostgreSQL not
installed/running locally at all) rather than a contrived edge case,
and explains precisely why After= alone has no mechanism to prevent
or even detect this, directly applying the chapter's own central
distinction between ordering and dependency.