Re: Row pattern recognition
Henson Choi <assam258@gmail.com>
From: Henson Choi <assam258@gmail.com>
To: Tatsuo Ishii <ishii@postgresql.org>, jian.universality@gmail.com
Cc: pgsql-hackers@postgresql.org, zsolt.parragi@percona.com, sjjang112233@gmail.com, vik@postgresfriends.org, er@xs4all.nl, jacob.champion@enterprisedb.com, david.g.johnston@gmail.com, peter@eisentraut.org, li.evan.chao@gmail.com
Date: 2026-06-23T14:28:18Z
Lists: pgsql-hackers
Attachments
- nocfbot-coverage.tgz (application/x-gzip)
Hi hackers, Following up on the coverage analysis I posted earlier: I've since pushed the work it proposed, so please find attached (coverage.tgz) an updated report that reflects the committed changes. In short, the branch now lands at the target we discussed. * What changed since the first report - New commits add the row pattern recognition coverage tests for the reachable lines, and tidy up the unreachable defensive/dead code (Assert conversions, removing the dead _equalRPRPattern body, and similar). - This is essentially the (b) path from the earlier mail: add the reachable-line tests plus the safe cleanups, while keeping the idiomatic guards as-is. * Measurement setup - Target: PostgreSQL RPR branch, modified-lines basis (RPR-base..RPR diff) - Build: gcc --enable-coverage with --with-llvm (LLVM JIT module included; both C and C++ instrumented) - Tests: make check-world (regression + TAP + contrib; no forced JIT settings) * Results (vs. the first report) - Modified-line coverage: 96.5% (2,608 / 2,702) -> 98.4% (2,635 / 2,679) - Functions: 99.4% (172 / 173) -> 100% (170 / 170) - Remaining 44 uncovered lines are the idiomatic defensive guards we agreed to keep on purpose: - enum-default branches - pg_unreachable() - public windowapi.h relpos guards I left these untouched rather than reworking them to chase ~100%, which matches my earlier inclination and our reading of where the line should sit. * On the earlier caveat The first report flagged that the reachable/unreachable classification was AI-assisted and might be wrong. That is now resolved in practice: each line I claimed was coverable was verified against a coverage build as I wrote its test, rather than resting on the classification. * What the report contains Each uncovered line carries a collapsible box stating: - Reachable / Unreachable classification + confidence - Reachable: the concrete SQL test that covers it - Unreachable: the reason it cannot execute, and the recommended source change Consecutive lines on the same straight-line flow (no branch in between) are merged into one box. * How to view tar xzf coverage.tgz # open coverage/index.html in a browser # -> pick a file -> expand the collapsible box under each red (uncovered) line * Contents - coverage/index.html : per-file coverage overview - coverage/html/ : per-file detail (source + uncovered-line analysis) - coverage/untested.md : checklist of uncovered lines Please review. Feel free to reply with any questions. Best regards, Henson
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Adjust cross-version upgrade tests for seg_out() fix
- 3e3d7875e956 19 (unreleased) cited
-
Rationalize error comments in partition split/merge tests
- ecb2508aaf9b 19 (unreleased) cited
-
Add fast path for foreign key constraint checks
- 2da86c1ef9b5 19 (unreleased) cited
-
Fix assorted pretty-trivial memory leaks in the backend.
- e78d1d6d47dc 19 (unreleased) cited
-
Add temporal FOREIGN KEY contraints
- 89f908a6d0ac 18.0 cited
-
Add trailing commas to enum definitions
- 611806cd726f 17.0 cited
-
Remove obsolete executor cleanup code
- d060e921ea5a 17.0 cited