Re: Small and unlikely overflow hazard in bms_next_member()
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Chao Li <li.evan.chao@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-12T12:33:04Z
Lists: pgsql-hackers
On Mon, 6 Apr 2026 at 14:01, Chao Li <li.evan.chao@gmail.com> wrote: > > On Apr 4, 2026, at 11:30, David Rowley <dgrowleyml@gmail.com> wrote: > > Not quite perfect as a set made first as a single word set that later > > becomes a multi-word set will be double counted. The number of > > operations on the sets is likely more important anyway, not the number > > of sets being created. The point is, multi-word sets are rare for most > > workloads. > > > > What tests did you run after adding the logs to collect the data? This is a method I might borrow in the future for similar investigations. "make check" then grep regression.diffs for the NOTICE message and pipe to "wc -l"
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix unlikely overflow bug in bms_next_member()
- e3e26d04bd52 19 (unreleased) landed