"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> I commited the following change to REL tree after 6.5.2.
> It might be late for Adriaan.
> ! if (SharedBufferChanged)
> TransactionIdAbort(xid);
> ! if (SharedBufferChanged && !TransactionIdDidCommit(xid))
> TransactionIdAbort(xid);
OK, I guess the point is that if VACUUM aborts at some time after
it's done its internal commit, this code would have un-done the
commit, thereby allowing HEAP_MOVED_OFF tuples to spring back to
life?
I was trying to figure out if this change might fix the duplicate-
tuples-after-failed-VACUUM problems that we've just been hearing
about. Certainly there is plenty of stuff going on in VACUUM after
its internal commit, so plenty of places that could elog(ERROR).
But it looks like the very first thing that happens after commit
is a scan to commit HEAP_MOVED_IN tuples and kill HEAP_MOVED_OFF
tuples, so this couldn't help much unless the failure happened
during that scan. Which doesn't seem really likely...
regards, tom lane
