RE: [HACKERS] BlowAwayRelationBuffers

> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
> 
> Adriaan Joubert <a.joubert@albourne.com> writes:
> > Hmmm, I got the following this morning on version 6.5.2 on DEC Alpha
> > during a vacuum verbose analyze. Ended up with duplicate rows of
> > everything.
> 
> Really!?  The referencecount failure doesn't surprise me a whole lot,
> given the refcount bugs that I fixed a couple months ago (no, those
> fixes are not in 6.5.* :-().  But VACUUM is supposed to be guaranteed
> proof against generating duplicate tuples by design --- that's what
> all the HEAP_MOVED_OFF and HEAP_MOVED_IN foofaraw is about.
> 
> Perhaps there is a glitch in the tuple validity checking logic for
> HEAP_MOVED_OFF/HEAP_MOVED_IN?  Anyone see it?
>

I commited the following change to REL tree after 6.5.2.
It might be late for Adriaan.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

*** xact.c.orig Wed Jan 12 17:53:19 2000
--- xact.c      Tue Oct 19 11:54:39 1999
***************
*** 733,741 ****       /*        * Have the transaction access methods record the status of        * this transaction
idin the pg_log relation. We skip it
 
!        * if no one shared buffer was changed by this transaction.        */
!       if (SharedBufferChanged)               TransactionIdAbort(xid);
       ResetBufferPool();
--- 733,742 ----       /*        * Have the transaction access methods record the status of        * this transaction
idin the pg_log relation. We skip it
 
!        * if no one shared buffer was changed by this transaction
!        * or this transaction has been committed already.        */
!       if (SharedBufferChanged && !TransactionIdDidCommit(xid))               TransactionIdAbort(xid);

       ResetBufferPool();