> -----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();