Re: Hmmm ... isn't count_nondeletable_pages all wet?

* Tom Lane:

> I am fairly sure that this bug explains problems previously reported
> by Merlin Moncure:
> http://archives.postgresql.org/pgsql-general/2006-10/msg01312.php
> and Florian Weimer:
> http://archives.postgresql.org/pgsql-general/2006-11/msg00305.php
> In both those cases, off-list investigation showed that the symptoms
> were caused by multiple index entries pointing to the same heap tuples,
> where one index entry matched the actual contents of the row and
> the other did not. In both cases this occurred for a fairly small
> number of rows that were clumped together into small ranges of blocks.
> It looks to me like this is perfectly explained by the theory that
> that range of blocks had been truncated away by a VACUUM at some point
> in the table's history, and that the non-matching index entries stemmed
> from an insert or update that occurred and then aborted after VACUUM had
> examined the blocks the first time but before it could return to check
> whether the blocks were still empty.

We did have auto-vacuum running, and while the table in question was
supposedly INSERT-only, some rollback might have occurred before the
corruption hit us, resulting in the dead tuples. So your explanation
makes sense to me (but I'm not really familiar with PostgreSQL
internals).

Regarding Scott's commment of other reports, I don't think we've
experienced the issue again; we've switched servers since then, and
the usage patterns have changed over time.

--
Florian Weimer <fweimer(at)bfk(dot)de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99