From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | kokdemir(at)gmail(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16849: index and table data inconsistency |
Date: | 2021-02-02 15:51:23 |
Message-ID: | 3716068.1612281083@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2021-02-03 14:20:30 | LookupExplicitNamespace() missing InvokeNamespaceSearchHook |
Previous Message | PG Bug reporting form | 2021-02-02 12:52:41 | BUG #16850: Inaccuracy in the documentation in the wal_receiver_status_interval parameter description |