Re:BUG #19492: intarray: fix variable stats leak in _int_matchsel

Started by zengman4 months ago2 messagesbugs
Beta feature

Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.

appliessuccessCI history

You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:

docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t139734
psql -h localhost -U postgres

Built from patchset v1 (message #1), September 20, 2026 at 12:25 AM.

Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:

git clone --branch t139734_1 https://github.com/hackorum-dev/postgres.git

In a checkout you already have, add the fork once:

git remote add hackorum https://github.com/hackorum-dev/postgres.git

then, for this patchset and every later one:

git fetch hackorum t139734_1 && git checkout t139734_1

Patchset v1 (message #1) is on t139734_1

Jump to latest
#1zengman
zengman@halodbtech.com

Patch attached. Also added a test case that exercises this code path
by creating a text operator with _int_matchsel as the restriction
estimator.

Regards,
Man Zeng

Attachments:

t139734_1
0001-Fix-variable-stats-leak-in-_int_matchsel-early-retur.patchapplication/octet-stream; charset=gb18030; name=0001-Fix-variable-stats-leak-in-_int_matchsel-early-retur.patchDownload+44-1
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: zengman (#1)
Re: BUG #19492: intarray: fix variable stats leak in _int_matchsel

"=?gb18030?B?emVuZ21hbg==?=" <zengman@halodbtech.com> writes:

Patch attached. Also added a test case that exercises this code path
by creating a text operator with _int_matchsel as the restriction
estimator.

Good catch, pushed. I didn't bother with the test case though ---
none of the other early exits in that function have test cases,
and I don't see why this one is any more fragile than the others.

regards, tom lane