Can a hash index become inconsistent for "no reason"?

Of course, when i say no reason i mean "apparently" no reason because nothing happened on the server (forced shutdowns, data corruption, deadlocks, etc...).

I ask this because, there was an application which executed a simple select on PostgreSQL:

select * from product where barcode = '9990000088355'

Which returned nothing, but there was a record in the table with barcode = 9990000088355. There was an index specific for this field, and after reindexing it, the problem was solved and the query fetched the record.

So, is there a reason for this issue to happen, and can i do something to prevent this or at least see if there is a problem with other indices of another tables?

FINALLY, after so much time i found the cause of this problem. I actually saw the machine where postgres was running suffering a hard reset, after that, the exact error happened.

Turns out the index i was using was a HASH index instead of the default B-Tree.
So, looking up on postgres documentation, the first thing i saw was a giant yellow warning explicitly stating about it's unsafety when a crash occurs.
Taken from the docs:


Caution

Hash index operations are not presently WAL-logged, so hash indexes might need to be rebuilt with REINDEX after a database crash if there were unwritten changes. Also, changes to hash indexes are not replicated over streaming or file-based replication after the initial base backup, so they give wrong answers to queries that subsequently use them. For these reasons, hash index use is presently discouraged.

What i did was simply drop the hash index and create a new one with B-tree algorithm. So far it seems to be the working solution.

StackExchange Database Administrators Q#116841, answer score: 3