OK, so that pretty much explains where the visible symptoms are coming from: somehow, the table got truncated but its pkey index did not get cleared out. So an insert creates an empty page zero, inserts a heap tuple there, tries to insert an index entry. The btree code sees there is an index entry for that key already, and tries to fetch the heap tuple for that index entry to see if it's dead (which would allow the insertion to proceed). But the block number the index is pointing at isn't there, so you get the quoted error message. The insertion rolls back, leaving a dead tuple that can be garbage-collected by autovacuum, after which it truncates the table again --- but of course without removing any index entries, except maybe one for TID (0,1) if that's still there. Lather rinse repeat.
But this brings us little closer to understanding the cause of the problem. How could the table have gotten truncated without vacuuming out the index?
Are you sure the only operations happening on that table are INSERT, DELETE, autovacuum? No DDL of any kind?
regards, tom lane
Not what I know. There are could be some updates as well, but they performed by the same cron as initial delete and they doesn't happened in that case because the cron script exit on the first database error. E.g. no one in my knowledge could write into that table except that single cron and autovacuum. And I have logged of the all queries with duration over 1ms.
