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

From Adriaan Joubert
Subject Re: [HACKERS] BlowAwayRelationBuffers
Date
Msg-id 387C3E78.CEA09236@albourne.com
Whole thread Raw
In response to BlowAwayRelationBuffers  (Adriaan Joubert <a.joubert@albourne.com>)
List pgsql-hackers
Tom Lane 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...

This is not the first time that I've ended up with duplicate tuples: I
even have a standard mechanism to deal with them :-(! Initially I thought
this was due to tables getting corrupted by having index entries that
were too large, but that has been fixed (and has caused no problems since
the fix you sent -- thanks again!), and this still happens. It seems to
happen most frequently when there have been a very large number of
changes to the tables between vacuums.

Adriaan



pgsql-hackers by date:

Previous
From: Adriaan Joubert
Date:
Subject: Re: [HACKERS] Re: Regress tests reveal *serious* psql bug
Next
From: "Hiroshi Inoue"
Date:
Subject: RE: [HACKERS] BlowAwayRelationBuffers