A PostgreSQL MCP server can remain available during failover and still return the wrong answer.
The connection retries against a replica.
The replica is behind.
A conversation combines a pre-failover result with a post-failover follow-up.
Every query succeeds, so the final answer looks complete.
Before production, give each workflow a consistency contract:
- eventual with a disclosed lag budget
- monotonic within one conversation
- read-your-writes
- point-in-time across multiple queries
- primary-only
Then make source identity, schema version, snapshot marker, observed time, and freshness part of material results.
Test more than promotion:
- idle pooled connections
- active transactions
- prepared statements and DNS caches
- interrupted multi-query answers
- bounded retries
- conversation continuity
- schema and policy versions
- paused replay and catch-up
- failback
Never concatenate partial rows from the old primary with rows from the new one. If the answer cannot prove one consistency boundary, discard the partial result and return a structured retryable failure.
Availability is a transport property.
Trustworthy answers need a data contract.
Full test guide: MCP server for Postgres: test failover consistency, not only availability
답글 남기기