Binary read replicas in PostgreSQL, Part 2
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
This Part 2 cookbook on PostgreSQL binary read replicas covers how to route read traffic to replicas, and why a replica should be tuned for a single job. It recommends application-side routing over middleware, uses libpq's target_session_attrs to pick standby servers, and advises health checks that include replication lag.
Score
0.71total under rubric v2.0Contestedjudges differ by 0.43 on significance, 0.49 on new information
- Significance0.56
- Reader interest0.81
- Audience breadth0.45
- Practical relevance0.90
- Substantiated0.74
- Technical depth0.98
- New information0.81
- Counts against: Promotional0.02
- Counts against: Overclaim0.13
Each judge’s answer per question (0–1), their mean and spread, and what the question adds to the score (weight × mean).
| Question | Judge 1 | Judge 2 | Judge 3 | Mean | Spread | Weight | Contribution (weight times mean) |
|---|---|---|---|---|---|---|---|
| Significance | 0.56 | 0.35 | 0.78 | 0.56 | 0.43 , above the contested threshold | +0.25 | +0.140 |
| Reader interest | 0.79 | 0.72 | 0.93 | 0.81 | 0.21 | +0.20 | +0.163 |
| Audience breadth | 0.38 | 0.40 | 0.58 | 0.45 | 0.20 | +0.10 | +0.045 |
| Practical relevance | 0.93 | 0.85 | 0.91 | 0.90 | 0.07 | +0.15 | +0.134 |
| Substantiated | 0.58 | 0.80 | 0.83 | 0.74 | 0.25 | +0.10 | +0.074 |
| Technical depth | 1.00 | 0.95 | 0.98 | 0.98 | 0.05 | +0.10 | +0.098 |
| New information | 0.94 | 0.50 | 0.99 | 0.81 | 0.49 , above the contested threshold | +0.10 | +0.081 |
| Promotional | 0.02 | 0.02 | 0.01 | 0.02 | 0.01 | −0.15 | −0.003 |
| Overclaim | 0.11 | 0.15 | 0.12 | 0.13 | 0.04 | −0.15 | −0.019 |
| Sum of contributions | +0.714 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.714 | ||||||
Spread is the highest minus the lowest judge answer. marks a spread above 0.40: the judges disagree, and the story is marked contested.
Claim check
Claim check: 1 matches source · 7 no source given. Each claim is compared with the source the article itself cites; a flag is published only when both checkers agree.
No source givenVersion
In libpq, target_session_attrs=standby arrived in PostgreSQL 14 and load_balance_hosts=random in PostgreSQL 16.
The article gives no link or citation for it.
The article says “The first arrived in PostgreSQL 14 and the second in 16, but both are features of the client library”
The source says No source to compare with.
No source givenNumber
Patroni's REST API endpoint GET /replica returns 200 only from a running replica, and GET /replica?lag=16MB returns 503 from a replica further behind than the threshold, measured in bytes of WAL.
The article gives no link or citation for it.
The article says “GET /replica returns 200 only from a running replica”
The source says No source to compare with.
Matches sourceNumber
pgBackRest has a backup-standby option that copies most of the files from a replica, while the backup is still started and stopped on the primary.
The cited source says the same thing.
The article says “pgBackRest has a backup-standby option that copies most of the files from a replica (the backup is still started and stopped on the primary, so both have to be configured”
The source says “Backups can be made from a standby to reduce load on the primary. Only the few files that are not replicated are copied from the primary”
Source cited by the article: github.com/pgbackrest/pgbackrest
No source givenVersion
Since PostgreSQL 16, a logical replication slot can be created on a replica and logical decoding can run there.
The article gives no link or citation for it.
The article says “Since PostgreSQL 16, a logical replication slot can be created on a replica, and logical decoding can run there”
The source says No source to compare with.
No source givenVersion
transaction_timeout is available in PostgreSQL 17 and later.
The article gives no link or citation for it.
The article says “transaction_timeout (PostgreSQL 17 and later”
The source says No source to compare with.
No source givenCausal conclusion
A replica running a different operating system release from its primary can sort strings differently, making its block-for-block copied text indexes wrong on the replica so queries miss rows.
The article gives no link or citation for it.
The article says “A replica running a different release from its primary can disagree with the primary about how strings sort”
The source says No source to compare with.
No source givenCausal conclusion
Through a chain of replicas that all have hot_standby_feedback on, a long query at the bottom holds back vacuum on the primary however many hops away it is.
The article gives no link or citation for it.
The article says “a long query at the bottom holds back vacuum on the primary however many hops away it is, and cascading does not insulate the primary from it”
The source says No source to compare with.
No source givenCausal conclusion
Under remote_apply, a query that holds up replay on a synchronous replica holds up every commit on the primary waiting on it, for as long as max_standby_streaming_delay allows.
The article gives no link or citation for it.
The article says “a query that holds up replay on that replica holds up every commit on the primary that is waiting on it”
The source says No source to compare with.
Also covered by
No other coverage was clustered with this story.
Elsewhere
Elsewhere: HN 2 pts, not on front page
Recorded for context only, checked 24 Oct 2026, 08:53 UTC. It played no part in the ranking.