Re: [HACKERS] BlowAwayRelationBuffers

From: Adriaan Joubert <a(dot)joubert(at)albourne(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] BlowAwayRelationBuffers
Date: 2000-01-12 08:42:32
Message-ID: 387C3E78.CEA09236@albourne.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

> 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?
>
> 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Netra systems 2000-01-12 08:52:06 postgresql installation
Previous Message Adriaan Joubert 2000-01-12 08:26:34 Re: [HACKERS] Re: Regress tests reveal *serious* psql bug