RE: [HACKERS] BlowAwayRelationBuffers

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Adriaan Joubert" <a(dot)joubert(at)albourne(dot)com>
Cc: <pgsql-hackers(at)postgreSQL(dot)org>
Subject: RE: [HACKERS] BlowAwayRelationBuffers
Date: 2000-01-12 09:02:33
Message-ID: 000201bf5cdb$c31fd620$2801007e@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Oliver Elphick 2000-01-12 10:31:43 Re: [HACKERS] CREATE TABLE ... PRIMARY KEY kills backend
Previous Message Netra systems 2000-01-12 08:52:06 postgresql installation