Key takeaway
A reproducible join can still combine rows that never belonged to the same committed view. Establish the snapshot boundary before interpreting the package.
The inconsistency can arrive before the join
A recipient receives an order table and an order-line table. Every identifier matches, the files parse, and the join produces the expected number of rows. Yet the order status comes from before a source transaction while the quantity comes from after it. Nothing is wrong with the join arithmetic. The export assembled two different database views into one apparently coherent package.
This is a specific acceptance question: do these approved tables describe the same committed read point? It differs from asking whether the exporter retrieved every page, whether the keys have the right multiplicity, or whether a manifest identifies the delivered files. Each check can pass while the snapshot question remains unanswered.
Reconstruct the mixed pair
Consider this hypothetical fixture. Before transaction T commits, order O1 is open and its line quantity is four units. T changes the parent status to closed and the child quantity to eight in one transaction. After commit, the pair is closed/eight. The example assumes that both fields really are changed atomically in this source; an owner must establish that fact for a real system.
The exporter reads the parent before T commits and the child afterward. It delivers open/eight. That pair is absent from both committed states in the fixture. Counting one distinct order and validating one-to-one keys would not detect the mixed read. A checksum would accurately identify the inconsistent files without correcting their meaning.
The receiving test should therefore compare the coordinated extraction with a known concurrent-change fixture. It should distinguish a valid earlier snapshot from a valid later one, rather than demand whichever state happens to be latest when the reviewer opens the result.
| Illustrative read boundary | Parent status | Child quantity | Decision |
|---|---|---|---|
| Before T commits | Open | 4 units | Consistent earlier view |
| After T commits | Closed | 8 units | Consistent later view |
| Parent before; child after | Open | 8 units | Hold mixed extraction |
A transaction label is not enough
PostgreSQL 18 documents Read Committed as its default isolation level. Each ordinary SELECT sees data committed before that command starts. Two successive SELECT commands can therefore observe different concurrent commits even inside one transaction. Merely recording that an exporter used a transaction does not settle the question.
PostgreSQL Repeatable Read instead uses the snapshot established by the first non-transaction-control statement for subsequent reads. That is useful evidence for a read-only extraction when all relevant reads actually use that transaction. Record the isolation level, snapshot-establishing step, reader connections and whether any part ran outside the boundary. Do not substitute a filename timestamp for those facts.
These are PostgreSQL guarantees, not a promise about every product with a similarly named setting. A stable snapshot also does not prove that earlier application transactions respected all business rules. The manual distinguishes snapshot visibility from serializable execution; the article’s acceptance claim is deliberately narrower.
Parallel readers need coordination
Two workers that independently begin Repeatable Read transactions need not see the same view. Another transaction can commit between their starts. The source documentation describes exporting a snapshot and importing it into other transactions so that those readers share the first transaction’s view of pre-existing data.
That mechanism has a lifetime. An exported snapshot remains available for import only until its exporting transaction ends. An exporter that closes the coordinator before a delayed worker imports the snapshot cannot cite the intended design as proof that the worker joined it. Retain observed import outcomes and the actual reader membership, rather than an unverified diagram.
The coordination record must also identify what lies outside it: another database, an API response, a separately retrieved attachment or a nontransactional value. Those objects need their own consistency agreement. Do not extend one database’s snapshot guarantee across a boundary it never controlled.
Leave an inspectable extraction record
For the fixture, the decision is to hold open/eight and request a coordinated replacement. The completed record names the database and isolation behavior, source transaction fixture, tables, reader sessions, shared-snapshot evidence where applicable, covered queries and unresolved external objects. It also retains the earlier rejected package identity so a later result cannot silently reuse it.
Ask the source owner for one bounded internal demonstration before promising a recurring delivery. The diligence question builder can capture the required evidence; the inventory can describe the affected tables and missing layers. Access to perform that internal check and permission to disclose its resulting records remain separate decisions. Snapshot consistency establishes a read boundary, not ownership, confidentiality clearance or buyer acceptance.