Re: First-draft release notes for next week's releases

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2014-03-17 21:09:10 +0000, Greg Stark wrote:
>> That said, it would be nice to actually fix the problem, not just
>> detect it. Eventually vacuum would fix the problem. I think. I'm not
>> really sure what will happen actually.

> Indexes will quite possibly stay corrupted. I think. If there was a
> index lookup for a affected row, the kill_prior_tuple logic will have
> quite possibly have zapped the index entry.

Whether it did or not, there's no way for the index entry to reach the
now-live tuple version (if it was a HOT update), so the question is moot.
What seems more interesting is whether REINDEX could fix the problem,
but at least with the current logic in catalog/index.c the answer seems
to be "no".

It's possible that a REINDEX attempt would work to detect whether you have
a problem (ie, see if you get one of the errors I just added). I'm not
sure that's bulletproof though.

> I think the best way to really cleanup a table is to use something like:
> ALTER TABLE rew ALTER COLUMN data TYPE text USING (data);
> where text is the previous type of the column. That should trigger a
> full table rewrite, without any finesse about tracking ctid chains.

Um... don't we have logic in there that's smart enough to short-circuit
that?

regards, tom lane