Skip site navigation (1) Skip section navigation (2)

Re: Recalculating OldestXmin in a long-running vacuum

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Gregory Stark <gsstark(at)mit(dot)edu>, pgsql-patches(at)postgresql(dot)org, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Subject: Re: Recalculating OldestXmin in a long-running vacuum
Date: 2007-02-19 19:07:33
Message-ID: 45D9F575.9030503@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-patches
Alvaro Herrera wrote:
> Tom Lane wrote:
>> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
>>> Tom Lane wrote:
>>>> BTW I've got serious reservations about whether this bit is safe:
>>>>
>>>>> + 			/* The table could've grown since vacuum started, and there
>>>>> + 			 * might already be dead tuples on the new pages. Catch them
>>>>> + 			 * as well. Also, we want to include any live tuples in the
>>>>> + 			 * new pages in the statistics.
>>>>> + 			 */
>>>>> + 			nblocks = RelationGetNumberOfBlocks(onerel);
>>>> I seem to recall some assumptions somewhere in the system that a vacuum
>>>> won't visit newly-added pages.
>>> Hmm, I can't think of anything.
>> I think I was thinking of the second risk described here:
>> http://archives.postgresql.org/pgsql-hackers/2005-05/msg00613.php
>> which is now fixed so maybe there's no longer any problem.  (If there
>> is, a change like this will convert it from a very-low-probability
>> problem into a significant-probability problem, so I guess we'll
>> find out...)
>>
>> I still don't like the patch though; rechecking the relation length
>> every N blocks is uselessly inefficient and still doesn't create any
>> guarantees about having examined everything.  If we think this is
>> worth doing at all, we should arrange to recheck the length after
>> processing what we think is the last block, not at any other time.
> 
> Was this revisited?

Arranging the tests has taken me longer than I thought, but I now 
finally have the hardware and DBT-2 set up. I just finished a pair of 2h 
tests with autovacuum off, and continuous vacuum of the stock table. I'm 
trying to get the results uploaded on some public website so we can all 
see and discuss them.

> I'm wondering if there has been any effort to make this work in
> conjunction with ITAGAKI Takahiro's patch to correct the dead tuple
> count estimate.

No. I'll have to take a look at that patch...

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-patches by date

Next:From: Simon RiggsDate: 2007-02-19 19:38:41
Subject: Re: Deadlock with pg_dump?
Previous:From: Greg SmithDate: 2007-02-19 18:58:14
Subject: Re: [PATCHES] WIP patch - INSERT-able log statements

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group