Re: BUG #18855: Using BRIN index with int8_bloom_ops produces incorrect results
Tomas Vondra <tomas@vondra.me>
From: Tomas Vondra <tomas@vondra.me>
To: arseniy.mukhin.dev@gmail.com, pgsql-bugs@lists.postgresql.org,
PG Bug reporting form <noreply@postgresql.org>
Date: 2025-03-19T17:11:07Z
Lists: pgsql-bugs
Attachments
- 0001-Keep-decompressed-filter-in-brin_bloom_union.patch (text/x-patch) patch 0001
On 3/19/25 14:43, Tomas Vondra wrote: > > ... > > I'll get this fixed shortly. Unfortunately, this means the "bloom" > filters may be broken - not just those built in parallel, the union > method can be triggered due to concurrent activity too. > Here's a more complete version of the fix, along with a proper commit message, etc. While working on this, I realized there's a second (less severe issue, in that it fails to free the decompressed filters. I believe this would be mostly harmless before parallel builds, because we'd merge only one summary at a time, I think. With parallel builds it may be much worse, but I'm yet to try how bad. FWIW I think the minmax-multi has a similar memory leak. regards -- Tomas Vondra
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Keep the decompressed filter in brin_bloom_union
- 6be02bbc884b 14.18 landed
- e064b770c081 15.13 landed
- ebcc799a772e 16.9 landed
- cb0ad70b8e47 17.5 landed
- 818245506c28 18.0 landed