Bind multi-query AI retrieval to one PostgreSQL read view

Choose the content question before choosing an isolation label

A fictional retrieval adapter reads document metadata, then its chunks, before assembling bounded model context. Both reads can be individually valid while the application lacks evidence that they describe one usable content view. The question is narrower than whether its database role may read those rows.

This profile selects PostgreSQL 18 documentation, one direct session S-A and one exclusively owned transaction T-A. Trusted code owns two fixed ordinary reads: Q-M selects the current revision of admitted document D-A; Q-C selects chunks of D-A restricted to exactly the revision returned by Q-M. Neither read locks rows or runs custom functions. No generated SQL is accepted.

The design is conditional, with no database or adapter inspected. Every ledger and card below is PROPOSED_UNRUN. The labels describe intended associations, not constructed queries or observed results.

Separate the read mode from the read view

PostgreSQL’s transaction-characteristics reference treats isolation and read-only access as different characteristics. Current-transaction settings do not establish subsequent transactions’ modes. Isolation cannot change after the first query or data-modification statement; a transaction-setting command without an existing transaction warns and has no effect.

Consequently, evidence saying only “read-only” or “setup sent” is insufficient for this selected adapter. Require supported evidence of the effective modes and actual transaction boundary before Q-M, then preserve the same session and transaction through Q-C. This article supplies no driver, connection-pool or configuration recipe.

The existing reporting execution profile covers effective rights and callable-code restrictions. Those remain separate prerequisites; choosing a content view grants no extra rows, columns or execution authority.

Place the snapshot at the documented first-read boundary

PostgreSQL’s isolation chapter explains that ordinary Read Committed reads take statement snapshots, so successive reads can observe intervening commits. Repeatable Read uses the snapshot at the start of the transaction’s first non-transaction-control statement. In this narrowly declared profile, Q-M is that first statement.

A successful transaction-start receipt is therefore not the chosen snapshot’s timestamp. Record which operation actually established the read boundary. An earlier data query, another session or an unknown adapter path invalidates this worksheet’s timing assumption.

The same chapter distinguishes a stable view from serial execution and business-rule correctness. Do not extend the selected ordinary-read analysis to sequence behavior, updates, row locks, custom functions, exported snapshots or a different isolation level. None is needed for this small decision.

Use a reachable two-read example

Invent a source state with metadata pointing to revision R-A and exactly two R-A chunks. A separately reviewed writer W-B publishes R-B by changing that metadata, removing the R-A chunks and inserting two R-B chunks in one transaction. These are symbolic business-state transitions, with no SQL or schema supplied. Actual atomic publication and valid source associations are unimplemented prerequisites.

PROPOSED_UNRUN — declared ordering only
1. T-A setup established; Q-M reads D-A revision R-A
2. W-B commits its complete R-B replacement
3. Q-C asks only for D-A / R-A chunks
4. Admission checks association, bounds and current rights

Under the declared later Read Committed view, Q-C has no R-A chunks to return. It does not return R-B chunks: its revision restriction still says R-A. Under the selected Repeatable Read view established at Q-M, the earlier R-A chunks remain visible to that ordinary read. These are conditional expectations from the specified ordering, not measured database outcomes.

A missing revision is an availability or association failure to report. Broadening Q-C to “whatever is current” would change the trusted read contract. Do not hide the missing result by silently attaching R-B chunks to metadata already selected as R-A.

Review eight inert retrieval cards

Keep current authorization outside the old content snapshot

A valid historical document view can still be inappropriate to send now. Re-establish current object and chunk rights under a separately supported release boundary. An authorization row read inside an older content snapshot cannot, by itself, prove that access remains permitted. This guide supplies no revocation coordinator or atomic authorization-to-model-dispatch implementation.

Also require trusted query definitions, business-consistent writer behavior, supported adapter boundaries, bounded work and output, and an established complete result. A row-count match alone cannot establish the right content. Unknown or failed completion must not be relabeled as a successful context build.

Keep the evidence minimized: request/profile references, selected revision, declared read association and dispositions suffice for this proposed worksheet. No raw document bodies, prompts, credentials or connection details belong in its ordinary review record.

Report the limits of this documentation exercise

Both required official bodies identify PostgreSQL 18 documentation. They establish no installed patch, actual session, driver behavior or enforced application profile. No SQL was constructed or executed for these proposed cases, and no database, transaction, connection, schema, runtime fixture, API or model operation occurred.

Boundary is prelaunch and does not ship this retrieval transaction coordinator. Its synthetic action exercise and existing mock evidence address different behavior. This read-view worksheet promises neither latest data, universal integrity, current authority, safe callable code nor guaranteed completion.