Re: [HACKERS] BlowAwayRelationBuffers - Mailing list pgsql-hackers

From Alfred Perlstein
Subject Re: [HACKERS] BlowAwayRelationBuffers
Date
Msg-id 20000112031308.S9397@fw.wintelcom.net
Whole thread Raw
In response to Re: [HACKERS] BlowAwayRelationBuffers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
* Tom Lane <tgl@sss.pgh.pa.us> [000112 00:56] wrote:
> 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?
> 
> Given that this was on an Alpha, it could be a 64-bit-platform-
> dependency kind of bug...

We've seen this on postgresql 6.5.3 on i386+FreeBSD 4.0, the only
way I was able to fix it was by dumping the entire table, running
sort on it and re-importing it.

Btw, I'd be interested in your opinion on the issues I recently
brought up with libpq when you have the time.

-Alfred



> 
>             regards, tom lane


pgsql-hackers by date:

Previous
From: "Oliver Elphick"
Date:
Subject: Re: [HACKERS] CREATE TABLE ... PRIMARY KEY kills backend
Next
From: Adriaan Joubert
Date:
Subject: Re: [HACKERS] BlowAwayRelationBuffers