From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Birch <sbirch(at)ironmountainsystems(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] HEAP_MOVED_IN error during vacuum? |
Date: | 1999-12-31 02:05:10 |
Message-ID: | 16274.946605910@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Birch <sbirch(at)ironmountainsystems(dot)com> writes:
> When I vacuum the database (PostgreSQL 6.5.3 on SuSE 6.3 Linux, 2.2
> kernel), I get the following error message:
> ERROR: HEAP_MOVED_IN was not expected.
> Can anyone tell me what a HEAP_MOVED_IN error is - I checked the
> source but was not familiar enough to understand it? Any ideas on why
> trim() may have cause it?
When VACUUM moves a tuple from one disk page to another (to compact the
table), the original tuple is marked HEAP_MOVED_OFF and the copy is
marked HEAP_MOVED_IN temporarily, until the VACUUM is ready to commit.
This is supposed to ensure that a failure partway through VACUUM won't
corrupt your table by leaving you with two copies of the same tuple.
(The HEAP_MOVED_OFF copy is valid until VACUUM commits, and the
HEAP_MOVED_IN copy is valid afterwards.)
I haven't heard of other reports of this error message, so I suspect
you have found some hard-to-hit boundary condition error in VACUUM's
data-shuffling logic. I guess that the reason you don't see the error
after a single trim() is that not very much data-shuffling is needed to
compact the table after just one tuple update.
What we need is a reproducible test case so we can chase down the bug
--- any chance you can provide one?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-12-31 03:34:55 | Re: [HACKERS] Is backend-libpq's "PQexec/PQfn/portal" code dead? |
Previous Message | Tom Lane | 1999-12-31 01:50:26 | Is backend-libpq's "PQexec/PQfn/portal" code dead? |