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

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 →
  1. Adjust cross-version upgrade tests for seg_out() fix

  2. Rationalize error comments in partition split/merge tests

  3. Add fast path for foreign key constraint checks

  4. Fix assorted pretty-trivial memory leaks in the backend.

  5. Add temporal FOREIGN KEY contraints

  6. Add trailing commas to enum definitions

  7. Remove obsolete executor cleanup code