Thanks for the advice. I re-indexed and reloaded a pg_dumpall into a spare server - no errors. Will run pg_catcheck asap.
regards,
Andy
Andy Halsall <andyh@xxxxxxxxxx> writes:
> db=# select * from xxxxx where col_a = 4675635;
> col_a | col_b | col_c | col_d | col_e | last_modified
> --------+-------------+-----------------+-----------+---------------+---------------
> | | | | |
> (1 row)
> Row 4675635 is very odd - NULL columns and at the same time retrievable by a value in col_a.
Doesn't seem particularly surprising if col_a is indexed. That query
would choose an indexscan plan, which would normally not bother to
re-verify the index condition against heap tuples found via the index.
If you're continuing to use this damaged database, it might be a good
idea to try to REINDEX all your indexes. That'd be particularly
useful for primary/unique indexes, since if corruption has led to
any apparent duplicate rows, the reindex would fail and complain.
But in any case it'd clean up heap-vs-index inconsistencies like the
above, as well as repairing any cases where the corruption was in an
index rather than heap.
Another test I'd strongly recommend is to see if you can pg_dumpall
and reload into a spare server. That might catch forms of data
corruption that reindexing would not, such as violated CHECK constraints.
regards, tom lane
