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? I'm thinking that there should be a single comment somewhere that explains exactly how the 2-pass algorithm works. The comment in vacuum_log_cleanup_info seems to have the most info, but there's a few pieces still missing. Also, found a typo: + * pass anyways). But this gives us two lareg benefits: -- Jim C. Nasby, Database Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
