> > 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. Kind Regards, Maksym
