Обсуждение: 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