Re: BUG #18855: Using BRIN index with int8_bloom_ops produces incorrect results

On 3/18/25 21:39, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference: 18855
> Logged by: Arseniy Mukhin
> Email address: arseniy(dot)mukhin(dot)dev(at)gmail(dot)com
> PostgreSQL version: 17.4
> Operating system: Ubuntu 24.04.2 LTS
> Description:
>
> PostgreSQL 17.4 (Debian 17.4-1.pgdg120+2) on x86_64-pc-linux-gnu, compiled
> by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
>
> In this example, the query using the index returns 0 rows, but the query
> using seqscan returns 1 row.
>
> How to reproduce:
>
> -- dataset
> drop table if exists t1;
> create table if not exists t1 (a bigint);
> insert into t1 (a) select x from generate_series(1,300000) as x;
> create index t1_a_brin_idx on t1 using brin (a int8_bloom_ops);
> analyse;
>

Thanks for the report, I can reproduce it too - but I had to add ANALYZE
before the CREATE INDEX, so that it triggers a parallel BRIN build.

The bug is pretty trivial - the brin_bloom_union() does this with the
summaries it's expected to merge:

filter_a = (BloomFilter *) PG_DETOAST_DATUM(col_a->bv_values[0]);
filter_b = (BloomFilter *) PG_DETOAST_DATUM(col_b->bv_values[0]);

and then it merges "b" into "a". But it never updates col_a to point to
the merged summary. The fix is to do something like this:

if (PointerGetDatum(filter_a) != col_a->bv_values[0])
{
pfree(DatumGetPointer(col_a->bv_values[0]));
col_a->bv_values[0] = PointerGetDatum(filter_a);
}

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.

regards

--
Tomas Vondra