Re: PG19 regression in ecd9288624a: JSON_ARRAY() indexes that go stale

From: Manu <manuelreyesbravo(at)gmail(dot)com>
To: Nikolay Samokhvalov <nik(at)postgres(dot)ai>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, jian he <jian(dot)universality(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, shihao zhong <zhong950419(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: PG19 regression in ecd9288624a: JSON_ARRAY() indexes that go stale
Date: 2026-11-04 14:57:49
Message-ID: 179380426902.1592062.15316504761016003822@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Nik,

On Tue, Nov 3, 2026 at 10:37 PM Nikolay Samokhvalov <nik(at)postgres(dot)ai>
wrote:
> True for scalars, but accepting arrays of them here is new in 19.

Right, I missed it: my line about floats covered scalars only, and I
never ran arrays with extra_float_digits or bytea_output changed.

Your repro on REL_19_STABLE a8e54f3dad3 with v5 returns 0 rows through
the index and 1 with a seq scan; 18.6 and master 73a28d2733a with v5
reject the CREATE INDEX. float4[], bytea[], point[], box[] and
circle[] behave the same, also as an array of a domain, as a 2-D
array and as a domain over the array type: 24 cases, all stale on 19
with v5, all rejected on 18.6, on master with v5 and on 19 with your
patch (attached: measurements.txt and the script, repro-arrays.sql.txt).

> It is for REL_19_STABLE only, on top of v5: arrays of float4,
> float8, bytea and the geometric types, or of domains over them, are
> mutable.

I found no type missing from your list. The built-in types whose
output function is IMMUTABLE on REL_19_STABLE and STABLE on master are
your ten plus pg_mcv_list and pg_brin_minmax_multi_summary, which have
no array type. In the regression database I also hashed the JSON of
every built-in column under extra_float_digits, bytea_output,
DateStyle, IntervalStyle, TimeZone, lc_monetary and lc_numeric; the
only types whose output changed with an IMMUTABLE output function on
19 are the same ten (gucprobe.sql.txt, attached too).

The patch applies with git am on top of v5, builds with assertions
and no warnings, and passes make check and check-world; without the
jsonfuncs.c hunk the new test fails. Of the 340 types we try on 19 it
rejects eleven more than v5 (arrays of your ten and of a domain over
float8), none that 18.6 accepts, and no scalars.

One nit: in a REL_19-only patch, "On master the output functions of
these types are STABLE" might read better as "e75fcc9867f made them
STABLE in 20 but was not backpatched".

An option for Andrew: making every array mutable on 19, as in 18,
also closes this, but rejects 47 more types that v5 and your patch
accept, among them int4[] and text[], whose output no setting changed.

regards,
Manu

Attachment Content-Type Size
measurements.txt text/plain 7.8 KB
repro-arrays.sql.txt text/plain 43.5 KB
gucprobe.sql.txt text/plain 5.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2026-11-04 14:59:17 Re: possible bug - xmlconcat is badly marked as immutable
Previous Message Phil Alger 2026-11-04 14:57:07 Re: Print latency percentiles in pgbench