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