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

From: JaeHyuck Sa <jaehyuck(dot)sa(dot)dev(at)gmail(dot)com>
To: Manu <manuelreyesbravo(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 06:10:16
Message-ID: CAKs5thwFvKAxjzWUY_ddPZg2tWYYoqtLNg_MPQ+8Adu7oVzV2w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Manu,

Thanks for v3.

In my last mail I said the new paragraph in the commit message covers
the index scan / seq scan mismatch, but I missed a case. 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. A
REINDEX from a new session fixed it. This seems to be general
PostgreSQL behavior rather than anything in v3, so perhaps you could
add a few words to that paragraph, e.g. "need a REINDEX from a session
started after the update".

Regards,
Jaehyuck Sa

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message shveta malik 2026-11-13 06:28:57 Re: BUG #19864: pg_get_publication_tables() gets cache lookup error after concurrent DROP PUBLICATION
Previous Message Michael Paquier 2026-11-13 06:02:28 Re: BUG #19842: pg_restore_extended_stats() rejects a faithful pg_dump of ANALYZE-produced range expression statisti