After upgrading we reindex all our databases, so I don't see it clear.
The difficulty here is finding a test case to work with.
El lun, 23 feb 2026 a las 21:27, Álvaro Herrera (<alvherre@kurilemu.de>) escribió:
On 2026-Feb-19, PG Bug reporting form wrote:
> CREATE TABLE r_has_stock ( > site_public_id varchar(10) NOT NULL, [...] > ) PARTITION BY HASH (site_public_id); [...] > Additional notes > • Database collation: en_US.UTF-8 > • Server encoding: UTF8 > • Explicit casts and COLLATE tests did not change behaviour. > • Issue appears only when index scan is used. > • Table and indexes originate from a cluster initially running > PostgreSQL 14.12 and later upgraded to 16.9. > • After reindex the issue was resolved. > > > Question > > Could this be related to HASH partitioning combined with PRIMARY KEY / > UNIQUE indexes, or to data created in older PostgreSQL versions and later > upgraded?
I would be pretty certain that the problem is related to collation changes, since the partition key is varchar and you said the problem disappeared after the reindex.
The solution is exactly that: reindex any indexes potentially affected by collation changes as part of a platform upgrade.
-- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "No hay hombre que no aspire a la plenitud, es decir, la suma de experiencias de que un hombre es capaz"
