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