Re: [pgsql-patches] Recalculating OldestXmin in a long-running vacuum - Mailing list pgsql-patches

From Tom Lane
Subject Re: [pgsql-patches] Recalculating OldestXmin in a long-running vacuum
Date
Msg-id 20457.1170613409@sss.pgh.pa.us
Whole thread Raw
In response to Re: [pgsql-patches] Recalculating OldestXmin in a long-running vacuum  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: Recalculating OldestXmin in a long-running vacuum  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-patches
Heikki Linnakangas <heikki@enterprisedb.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.

            regards, tom lane

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] \copy (query) delimiter syntax error
Next
From: Jeremy Drake
Date:
Subject: Re: [HACKERS] writing new regexp functions