RE: [HACKERS] BlowAwayRelationBuffers

> -----Original Message-----
> From: owner-pgsql-hackers(at)postgreSQL(dot)org
> [mailto:owner-pgsql-hackers(at)postgreSQL(dot)org]On Behalf Of Tom Lane
>
> Adriaan Joubert <a(dot)joubert(at)albourne(dot)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(at)tpf(dot)co(dot)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 id in 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 id in 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();