Exercise 1: Physical vs. Logical Replication, and a Scenario Only Logical Handles — Possible Solution
====================================================================

PHYSICAL (STREAMING) REPLICATION
------------------------------
Per this chapter, "streaming replication works by continuously
shipping WAL records from a primary server to one or more standby
servers, which replay those records to stay in sync... this is
'physical' replication — a byte-for-byte, block-level copy of the
entire database cluster. A replica built this way is an exact
physical copy: it can't have a different schema, can't replicate only
a subset of tables, and in the classic setup is read-only."

LOGICAL REPLICATION
------------------------------
Per this chapter, "logical replication... replicates actual row-level
changes via a publish/subscribe model (CREATE PUBLICATION / CREATE
SUBSCRIPTION), rather than raw physical WAL bytes... this unlocks
real capability physical replication can't offer: replicating just a
subset of tables rather than the whole cluster, replicating between
different major Postgres versions... and the subscriber remains a
genuinely independent, writable database that simply happens to
receive a stream of changes for the tables being replicated."

THE CORE DIFFERENCE
------------------------------
Physical replication copies the database at the raw storage level —
an exact clone, whole-cluster only. Logical replication copies at the
level of actual row changes for specifically chosen tables, to a
target database that stays independently writable and can even run a
different Postgres major version.

A CONCRETE SCENARIO ONLY LOGICAL REPLICATION HANDLES
------------------------------
An organization needs to upgrade from Postgres 13 to Postgres 16 with
minimal downtime, and only wants to replicate three specific tables
(orders, customers, products) out of a much larger database into a
new reporting system running on the newer version, while leaving the
rest of the original schema behind entirely. Physical/streaming
replication cannot do this at all — per this chapter, it requires an
exact, whole-cluster copy on the SAME major version, with no ability
to select a subset of tables. Logical replication handles this
scenario directly: a publication can be created for just those three
tables, a subscription set up on the new Postgres 16 database, and
replication proceeds across the version boundary, syncing only the
selected tables — exactly the capability the chapter names as unique
to logical replication.

WHY THIS WORKS AS AN ANSWER
------------------------------
It defines both mechanisms precisely using the chapter's own wording,
identifies the core structural difference, and constructs a concrete
scenario combining BOTH of logical replication's own named unique
capabilities (subset of tables, cross-version) that physical
replication genuinely cannot satisfy.