On Fri, Aug 21, 2009 at 5:15 PM, Alvaro
> I wonder if this could be explained by xid=6179 not marked as committed
> in clog. I'd try flipping that bit and see what happens ...
Well nothing's going to help much now. Firstly, once the hint bit gets
set nothing second-guesses that and checks the clog anyways. And
secondly the new version of the tuple is already vacuumed.
Either of two things are true.
Either transaction 6179 committed, which would explain why the toast
tuples are missing. In which case sometime later this hint bit became
set and the new version pruned. I don't know if bad memory could cause
all that to happen, would the HOT pruning logic see the hint bit and
decide to prune based on that? I suppose a bad bit hitting the clog
could cause everything though.
Alternatively 6179 aborted but somebody along the way got that wrong
and marked the toast tuples dead (and maybe vacuumed them) thinking it
had committed. That's going to be harder to tell if that's what
happened because we don't have any pointers to the specific page in
the toast table. Not unless you can dump the whole index and find
pointers in there or can find the details in the wal log.
In response to
pgsql-bugs by date
|Next:||From: Radoslaw Zielinski||Date: 2009-08-21 16:38:30|
|Subject: Re: 8.4.0 data loss / HOT-related bug|
|Previous:||From: Tom Lane||Date: 2009-08-21 16:33:03|
|Subject: Re: 8.4.0 data loss / HOT-related bug |