On Tue, Aug 23, 2011 at 2:47 AM, Jim Nasby <jim@nasby.net> wrote:
> On Aug 22, 2011, at 1:22 AM, Pavan Deolasee wrote:
>> Hi All,
>>
>> Here is a revised patch based on our earlier discussion. I implemented
>> Robert's idea of tracking the vacuum generation number in the line
>> pointer itself. For LP_DEAD line pointers, the lp_off/lp_len is unused
>> (and always set to 0 for heap tuples). We use those 30 bits to store
>> the generation number of the vacuum which would have potentially
>> removed the corresponding index pointers, if the vacuum finished
>> successfully. The pg_class information is used to know the status of
>> the vacuum, whether it failed or succeeded. 30-bit numbers are large
>> enough that we can ignore any wrap-around related issues. With this
>
> + * Note: We don't worry about the wrap-around issues here since it would
> + * take a 1 Billion vacuums on the same relation for the vacuum generation
> + * to wrap-around. That would take ages to happen and even if it happens,
> + * the chances that we might have dead-vacuumed line pointers still
> + * stamped with the old (failed) vacuum are infinitely small since some
> + * other vacuum cycle would have taken care of them.
>
> It would be good if some comment explained how we're safe in the case of an aborted vacuum. I'm guessing that when
vacuumfinds any line pointers that don't match the last successful vacuum exactly it will go and re-examine them from
scratch?
>
Yeah. If we don't know the status of the vacuum that collected the
line pointer and marked it vacuum-dead, the next vacuum will pick it
up again and stamp it with its own generation number.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com