On Tue, Aug 23, 2011 at 2:47 AM, Jim Nasby <j...@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 vacuum finds 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
