Re: [PG19] Indexes from 18 miss rows after pg_upgrade

From: Andreas Karlsson <andreas(at)proxel(dot)se>
To: shihao zhong <zhong950419(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [PG19] Indexes from 18 miss rows after pg_upgrade
Date: 2026-10-21 13:17:12
Message-ID: 8b820df9-15b2-4e5d-b3a2-bc2edeb6eda7@proxel.se
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/17/26 05:32, shihao zhong wrote:
> > Is that still just a release note, or does it demand something more?
>
> I think it needs more. With LC_CTYPE C, text search changed too, not
> only pg_trgm. In a builtin C.UTF-8 database:
>
>     select to_tsvector('simple', 'foo—bar don’t naïve');
>     18.6:   'don’t':2 'foo—bar':1 'naïve':3
>     19rc1:  'bar':2 'don':3 'foo':1 'naïve':5 't':4
>
> In my upgrade test, every text search and pg_trgm index in ICU and
> builtin databases with LC_CTYPE C missed rows. Any accent or curly
> quote is enough.
>
> I did some history check and found fb1a18810f, the 18 notes said to reindex
> all of them, so I think pg_upgrade should name the indexes, as the
> patch does.

I disagree. What makes this different from any other change to a
function? Almost any change in output from a function can cause this.
And we have changed the behavior of functions before, e.g. in
fb1a18810f, and we have so far never added anything to check.c in
pg_upgrade for a case like this.

If this is something we want to change we should make this a larger
discussion. Maybe if it affected almost everyone but I do not think it does.

This feels like something which is best handled in the release notes.

> > Should that note be expanded?
>
> Yes. Stems also changed for english, german, swedish, lithuanian,
> french and norwegian.... The note may also need a cover extension like
> fuzzystrmatch, which changed in libc databases too.

Agreed, it should probably be expanded and made sure people understand
the scope of the issue.

Andreas

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Harrison Booth 2026-10-21 13:22:53 Re: [PATCH] Fix socket handle inheritance on Windows
Previous Message David Steele 2026-10-21 13:07:53 Re: Return pg_control from pg_backup_stop().