Postgresql: empty query response when there are records: failure or reason?

Question

PostgreSQL

I have a table with a set of records. The application gives a query to this table according to a certain condition and receives the result. At some point, something strange happens: a query that is guaranteed to return a set of rows returns an empty cursor. The database archive was restored at the time of the incident, research and analysis of the primary key and timestamp values ​​showed that at the time the query was executed, there were records in the table that met the condition. And there is a log entry with the text of the request and the result - 0 entries! And the same query on the restored archive returns the records, confirming that the records should have been found. But the log says - 0 entries.
Question: under what conditions can Postgresql return an empty result when there are actually records that match the query? A glitch, features that I don't know about, crooked hands, something else...
In connection with Vitsliputsli's advice, I think the following. No manipulations with the required records were made during the year. This means that:
- if the entries being searched were stuck in the cache and postgresql did not determine that the cache was invalid and continued to use it, the query would return those entries.
- if postgresql realized that the cache was out of date, it would query them again from the table, and return them too.
It turns out that regardless of the state of the cache, the query should have returned a non-empty result. And it's empty. And it happened suddenly, only once, and is not reproduced in any way. And what to do? Blame it on postgresql failure, or is there a reasonable reason for this phenomenon?

Answer 1

There is little information, but check carefully, perhaps there is some other code between the request and the response from the database, maybe there is an error in it?
I would add debugging information directly to the code where the response from the database comes from the condition of the sql used, and write the date, query parameters and the number of records in the result to the log. Based on the results, you can at least guarantee that this database is buggy.
Check the network connection to the database, especially if it is located on another server, though in this case you should get an error, but very often programmers are too lazy to check all cases (like if the previous call is error-free, then why check the next one).
Run the database and file system integrity check utilities. It’s trite to check the performance of the hardware, suddenly your RAM is buggy (although you would get out a lot of jambs where) or the hard disk controller fails (see the dmesg server logs at least).