A PostgreSQL replica is supposed to reproduce the primary's accepted history. That is why a valid but destructive DELETE can remove the same row from every standby without any part of replication failing.
The failure is historical
Failover chooses another current copy. When every current copy contains the unwanted transaction, promotion changes availability but not data.
PgSentry tested the distinction by writing a protected marker, creating a named recovery point, writing a later marker, and deleting the protected row through HAProxy. The deletion reached the primary and both replicas.
The source that still had the row
The recovery path restored a physical base backup into an isolated PostgreSQL instance, then replayed archived WAL only through the named target. Verification required the deleted row to be present and the later marker to be absent.
That second condition matters: recovery is not finding any copy where a row exists. It is reconstructing the intended point in history.
I now separate the mechanisms plainly: replication maintains another current copy; backup and WAL maintain recoverable history. One cannot substitute for the other.
Related project: PgSentry →