RE: [HACKERS] BlowAwayRelationBuffers

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> 
> "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?
>

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@tpf.co.jp