From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Birch <sbirch(at)ironmountainsystems(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Re:HEAP_MOVED_IN during vacuum - test case |
Date: | 2000-01-10 04:31:49 |
Message-ID: | 1886.947478709@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:
> I have now created a test case that demonstrate the HEAP_MOVED_IN during
> vacuum problem.
OK, I've sussed it. Dunno if you want the details, but briefly: the
code was using the last element of a list of target pages (pages that
had room to insert more tuples) as a sentinel point to know when to
stop trying to move tuples out of source pages. But there was also
an optimization in there to remove target pages from the target list
as soon as they got full (so as not to keep checking them). Sure
enough, with the right data pattern it was possible to remove the
last modified page from the target-page list before the source loop
got to it, and then everything falls over. I'm surprised we haven't
heard more complaints about this, actually --- it doesn't look like
the failure should be all that unlikely.
I have committed what I think is a proper fix into current sources,
but I don't really think it should be trusted until it's been through
a beta test cycle. Instead, attached is a very low-risk patch that
just dikes out the code that tries to remove target pages early.
This will result in some marginal slowdown when vacuuming huge
relations, but I think it should be safe to plug into production
6.5.* servers.
Thanks again for the narrowly focused test case --- I suspect you
put quite a bit of time into developing it...
regards, tom lane
*** src/backend/commands/vacuum.c.orig Tue Jan 4 12:27:26 2000
--- src/backend/commands/vacuum.c Sun Jan 9 23:16:10 2000
***************
*** 1253,1258 ****
--- 1253,1259 ----
{
if (!vc_enough_space(to_vpd, tlen))
{
+ #if 0 /* this code is broken */
if (to_vpd != last_fraged_page &&
!vc_enough_space(to_vpd, vacrelstats->min_tlen))
{
***************
*** 1263,1268 ****
--- 1264,1270 ----
num_fraged_pages--;
Assert(last_fraged_page == fraged_pages->vpl_pagedesc[num_fraged_pages - 1]);
}
+ #endif
for (i = 0; i < num_fraged_pages; i++)
{
if (vc_enough_space(fraged_pages->vpl_pagedesc[i], tlen))
***************
*** 1517,1522 ****
--- 1519,1525 ----
WriteBuffer(cur_buffer);
cur_buffer = InvalidBuffer;
+ #if 0 /* this code is broken */
/*
* If no one tuple can't be added to this page -
* remove page from fraged_pages. - vadim 11/27/96
***************
*** 1534,1539 ****
--- 1537,1543 ----
num_fraged_pages--;
Assert(last_fraged_page == fraged_pages->vpl_pagedesc[num_fraged_pages - 1]);
}
+ #endif
}
for (i = 0; i < num_fraged_pages; i++)
{
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-01-10 04:35:17 | Number of index fields configurable |
Previous Message | Bruce Momjian | 2000-01-10 04:21:59 | Re: Postgres Features for 7.X |