RFC: PostgreSQL variable reconciliation during active Extended Query pipelines #6504

Problem to investigate

The PostgreSQL session verification loop explicitly terminates the session when an active Extended Query pipeline needs a second tracked parameter synchronized during the same pass. It also terminates when the resumed operation is not Execute. This came up as G8 in the twelve-month SET/session-variable review; the maintainer requested an issue and RFC for further analysis. No decision to retain or remove the restriction has been made.

Source endpoint: a832cbb22be47fffc7a7caf9b82d1f8e76b27171.

• Critical and dynamic verification loops: share pipeline_var_sync_pending; the second required synchronization logs “multiple parameters need syncing. Session will be destroyed” and returns -1.
• Verifier side effects: sets the pending variable/status and updates backend metadata. The verification pass is not a read-only diff.
• Pipeline predicate: libpq uses PQpipelineStatus, native uses native_unsynced_work. Equivalent client reachability needs proof.

Potential impact: an otherwise valid operation can depend on whether the selected backend already matches several supported logical session settings. This is source-confirmed control flow, not a reproduced client disconnect. Two client SETs alone do not establish the exact branch conditions.

Historical context

Introduced by 96bc66873, integrated in March 2026 through #5444. The earlier loop had no explicit second-parameter fatal check; that is not evidence that the earlier implementation handled all pipeline synchronization correctly.

Follow-up to closed #5432, which explains the simple-query/pipeline incompatibility and the decision to forward SET/single RESET through Extended Query. Forwarding the current SET does not itself define how to reconcile arbitrary pre-existing frontend/backend differences.

Investigation RFC in documentation PR #6491. The RFC is a draft; no implementation is approved.

Analysis required

• Establish minimal real-client sequences for libpq and native, including first backend use, prepared-statement cache hit/miss, Parse/Describe/Bind/Execute, and earlier unsynced work. Record actual backend identity, desired/materialized hashes, status stack and wire order.
• Separate pre-dispatch preparation from changes arising after backend work starts. Identify settings that affect Parse/Bind/name resolution as well as Execute.
• Trace internal setting command encoding, pending operation/result ownership, metadata commits/failure invalidation, error recovery through Sync, and implicit/explicit transaction boundaries.
• Compare preparing all state before dispatch, ordered internal Extended Query operations, and precisely documented restrictions with protocol recovery where possible. No parameter-name allowlist or removal of the count check without a general state model.
• Preserve exclusive ownership, truthful pooled state, execution-progress and transaction retry guards. Do not introduce Sync or replay client SQL merely to make preparation convenient.

Evidence and acceptance criteria

1. Deterministic branch-level tests plus real wire/state traces (or proof that a suspected sequence is unreachable in a given mode).
2. Matrix for zero/one/two/several differences across critical/dynamic groups, both drivers and supported build tiers; cache hit/miss, phase, client Sync/Flush boundaries, idle/active/failed transactions and rollback/savepoints.
3. First/later setting error and transport/cancel failure coverage: no duplicate execution, reordered client responses, accidental transaction completion, or backend returned with unverified state.
4. A reviewed RFC and maintainer decision defining supported behavior and any remaining client-visible error/disconnect boundaries, followed by an implementation plan and focused regression tests.

No runtime probes were executed for this report. Existing pipeline tests were inspected but do not establish deterministic coverage of this exact fatal branch.