Thread: BUG #16849: index and table data inconsistency
The following bug has been logged on the website: Bug reference: 16849 Logged by: Ibrahim Edib Kokdemir Email address: kokdemir@gmail.com PostgreSQL version: 12.2 Operating system: centos 7 Description: I have data in a varchar field like '092', '00000000169', '0000001' and so on. There is a btree index on this field. my searches are similar to below ones. select searched_field from searched_table where searched_field = '092'; When I search data, it uses the given index and returns no value. But when I disable index scan, it does a sequential scan and return data. We have witnessed this case in one index in our production(11.7) and staging(12.2) environments on same index. Then we dropped the index and recreate it. The problem is solved. But, to me, index and data must be consistent.
PG Bug reporting form <noreply@postgresql.org> writes: > I have data in a varchar field like '092', '00000000169', '0000001' and so > on. There is a btree index on this field. my searches are similar to below > ones. > select searched_field from searched_table where searched_field = '092'; > When I search data, it uses the given index and returns no value. But when I > disable index scan, it does a sequential scan and return data. > We have witnessed this case in one index in our production(11.7) and > staging(12.2) environments on same index. Then we dropped the index and > recreate it. The problem is solved. But, to me, index and data must be > consistent. Most likely you got bit by an operating-system locale change causing a change in sort order and thereby making the index self-inconsistent. See https://wiki.postgresql.org/wiki/Locale_data_changes There's work afoot to have Postgres automatically notice when the OS changes underneath it, but that's not done yet. regards, tom lane