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