Re: [HACKERS] BlowAwayRelationBuffers

From: Alfred Perlstein <bright(at)wintelcom(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Adriaan Joubert <a(dot)joubert(at)albourne(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] BlowAwayRelationBuffers
Date: 2000-01-12 11:13:08
Message-ID: 20000112031308.S9397@fw.wintelcom.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [000112 00:56] 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...

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Adriaan Joubert 2000-01-12 11:20:15 Re: [HACKERS] BlowAwayRelationBuffers
Previous Message Oliver Elphick 2000-01-12 10:31:43 Re: [HACKERS] CREATE TABLE ... PRIMARY KEY kills backend