Re: BUG #19602: Vuln46: citext split_part silently returns NULL for a zero field position instead of raising core sp

From: Manu <manuelreyesbravo(at)gmail(dot)com>
To: JaeHyuck Sa <jaehyuck(dot)sa(dot)dev(at)gmail(dot)com>
Cc: Aleksander Alekseev <aleksander(at)tigerdata(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org, 1217816127(at)qq(dot)com
Subject: Re: BUG #19602: Vuln46: citext split_part silently returns NULL for a zero field position instead of raising core sp
Date: 2026-11-13 19:54:56
Message-ID: 179459969625.858285.12508539351287151257@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Jaehyuck,

On Fri, Nov 13, 2026 at 3:10 PM Jaehyuck Sa
<jaehyuck(dot)sa(dot)dev(at)gmail(dot)com> wrote:
> In a session
> that had used the table under 1.8, I ran ALTER EXTENSION citext UPDATE
> and then REINDEX. The index was rebuilt with the 1.8 results, so a
> new session's index scan still missed rows that a seq scan found.

You are right: after a REINDEX in such a session, an index scan from a
new session found 0 of 500 matching rows and a seq scan found 500, and
after a REINDEX from a new session both found 500. A plain SQL function
changed with CREATE OR REPLACE does the same, so it is not specific to
citext. The same happens with a partial index predicate, a partition
key (an older session that had used the table kept routing new rows by
the 1.8 result) and a domain CHECK (an older session accepted a value
1.9 rejects). The attached v4 adds this to the commit message; the code
is unchanged.

Regards,
Manu

Attachment Content-Type Size
v4-0001-Make-citext-s-split_part-handle-field-positions-l.patch text/x-patch 12.3 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Previous Message Andrey Rachitskiy 2026-11-13 19:10:39 Re: BUG #19866: acldefault() emits invalid UTF-8 for a high-bit "char" value