Re: [HACKERS] HEAP_MOVED_IN error during vacuum?

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

In response to

Browse pgsql-hackers by date

  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?