Server closed the connection unexpectedly in Postgres
Comments on “Server closed the connection unexpectedly in Postgres”
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
Now-Next's Chris van Eijk tested what PostgreSQL's "server closed the connection unexpectedly" message hides, using Docker images 13 to 18 and six client libraries. The sentence comes from libpq, not the server, and the server log is the main clue. In an autocommit loop with kill -9, 77 of 100 failed statements had in fact committed, so blind retries risk duplicates. pg_xact_status sometimes reported lost transactions as committed after a crash. Most figures are the author's own measurements and have no independent source.
Why it ranked
No. 3 of 139 with a score of 0.74. The panel rated it highest on technical depth (0.98) and substantiated (0.94), lowest on significance (0.56).
- AI judgeJudge 2claude-haiku-5-5
- Deep, measured, reproducible investigation of a common PostgreSQL client error across drivers and versions; highly practical for backend builders, though narrow in scope and not a landmark.
- AI judgeJudge 3gpt-5.6-luna
- Extensive reproducible PostgreSQL and client-library measurements explain failure modes, observability gaps, network behavior, pooling, OOM kills, and commit ambiguity. It is highly actionable and technically deep, though primarily relevant to database and infrastructure practitioners.
Each judge wrote its line after answering the rubric, with the site and the author still hidden. Every answer behind this is in the table under Score.
Score
0.74total under rubric v2.3
- Significance0.56
- Reader interest0.81
- Audience breadth0.60
- Practical relevance0.90
- Substantiated0.94
- Technical depth0.98
- New information0.89
- Counts against: Promotional0.02
- Counts against: Overclaim0.11
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) |
|---|---|---|---|---|---|---|---|
| SignificanceHow much does this change what people in tech know or can do? | 0.60 | 0.35 | 0.72 | 0.56 | 0.37 | +0.24 | +0.134 |
| Reader interestWould a well-informed senior engineer or tech founder want to read this today, and likely pass it on? | 0.69 | 0.80 | 0.94 | 0.81 | 0.25 | +0.26 | +0.211 |
| Audience breadthHow many people who build technology does it concern? | 0.58 | 0.67 | 0.55 | 0.60 | 0.12 | +0.13 | +0.078 |
| Practical relevanceHow useful is it to someone who builds software or tech products? | 0.94 | 0.85 | 0.90 | 0.90 | 0.09 | +0.22 | +0.197 |
| SubstantiatedHow well is it backed? Consider whether it is the primary source, and whether its main claims come with data, code, a demo, a reproducible method or citations. | 0.98 | 0.90 | 0.94 | 0.94 | 0.08 | +0.05 | +0.047 |
| Technical depthHow technically substantive is it? | 1.00 | 0.95 | 0.98 | 0.98 | 0.05 | +0.05 | +0.049 |
| New informationDoes it contain information absent from the stories covered in the last 7 days (list provided)? | 0.84 | 0.85 | 0.99 | 0.89 | 0.15 | +0.05 | +0.045 |
| PromotionalIs it mainly marketing with little substance (a press release, ad or sponsored post with no real information)? A launch post that carries real news is not promotional. | 0.03 | 0.03 | 0.01 | 0.02 | 0.02 | −0.19 | −0.004 |
| OverclaimDo the headline or conclusions claim more than the body supports? | 0.12 | 0.12 | 0.08 | 0.11 | 0.04 | −0.11 | −0.012 |
| Sum of contributions | +0.744 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.744 | ||||||
Spread is the highest minus the lowest judge answer. marks a spread above 0.40: the judges disagree, and the story is marked contested.
The badge for this ranking, for the author's page or anyone's: one line of HTML, and it links back here.
<a href="https://rubric.hrih.si/editions/2026-11-05/3/"><img src="https://rubric.hrih.si/badge/2026-11-05/3.svg" alt="Ranked #3 on Rubric, 5 Nov 2026" width="231" height="28"></a>Claim check
Claim check: 1 matches source · 5 no source given · 2 couldn’t check. Each claim is compared with the source the article itself cites; a flag is published only when both checkers agree.
Matches sourceQuote
PostgreSQL's documentation recommends vm.overcommit_memory=2 as advice on the OOM killer, saying it "will lower the chances significantly".
The cited source says the same thing.
The article says “The documentation’s advice on the OOM killer is vm.overcommit_memory=2, which “will lower the chances significantly”
The source says “Although this setting will not prevent the OOM killer from being invoked altogether, it will lower the chances significantly and will therefore lead to more robust system behavior”
Source cited by the article: postgresql.org/docs/18/kernel-resources.html
Couldn’t checkQuote
The PostgreSQL documentation offers pg_xact_status for determining whether a transaction committed or aborted after the application and server become disconnected while a COMMIT is in progress.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “to determine whether their transaction committed or aborted after the application and database server become disconnected while a COMMIT is in progress”
The source says No passage could be compared.
Source cited by the article: postgresql.org/docs/18/functions-info.html
Couldn’t checkQuote
The PostgreSQL psql documentation describes exit code 2 as meaning the connection to the server went bad and the session was not interactive.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “the connection to the server went bad and the session was not interactive”
The source says No passage could be compared.
Source cited by the article: postgresql.org/docs/18/app-psql.html
No source givenVersion
With psycopg2 wheels 2.9.9 and later (bundled libpq 16.0 and newer), the server's reason no longer appears in the error message and pgcode is None.
The article gives no link or citation for it.
The article says “2.9.9 16.0 OperationalError None no”
The source says No source to compare with.
No source givenNumber
With six clients, an idle connection and a query sent 1 s after the network path died, failure came after about 951 s on Linux with tcp_retries2=15.
The article gives no link or citation for it.
The article says “All six clients, with an idle connection and a query sent 1 s after the path died, failed after about 951 s, nearly 16 minutes”
The source says No source to compare with.
No source givenNumber
In an autocommit INSERT loop with synchronous_commit on, 77 of 100 failed statements had actually committed their row.
The article gives no link or citation for it.
The article says “on 100 77 0 of 214,597”
The source says No source to compare with.
No source givenCausal conclusion
pg_xact_status reported 'committed' for interrupted transactions whose rows were gone after kill -9 during COMMIT, because recovery reused the xid; this occurred in 6 of 8 rounds in the first run and 8 of 8 in the second.
The article gives no link or citation for it.
The article says “That happened in 6 of 8 rounds in the first run and 8 of 8 in the second”
The source says No source to compare with.
No source givenGeneralization
The same COMMIT-time kill -9 produces identical client output whether the transaction was lost or committed, so the error alone cannot tell whether the COMMIT went through.
The article gives no link or citation for it.
The article says “Same output, opposite outcome, on 17 and 18”
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 5 Nov 2026, 05:46 UTC. It played no part in the ranking.