RE: [HACKERS] BlowAwayRelationBuffers

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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?
>

Yes.

> 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

Certainly when BlowAwayRelationBuffers() is called,commit to HEAP_
MOVED_IN(OFF) was already completed.
However it seems that the pages which are about to be truncated
are not touched.

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp