Re: Hot Standby (commit fest version - v5) - Mailing list pgsql-hackers

I wonder if we should refactor lazy_scan_heap() so that *all* the real work of collecting information about dead tuples happens only in heap_page_prune(). Frankly, there is only a rare chance that a tuple may become DEAD after the pruning happened on the page. We can ignore such tuples; they will be vacuumed/pruned in the next cycle.

This would save us a second check of HeapTupleSatisfiesVacuum on the tuples which are just now checked in heap_page_prune(). In addition, the following additional WAL records are then not necessary because heap_page_prune() must have already logged the latestRemovedXid.

+ /*
+  * For Hot Standby we need to know the highest transaction id that will
+  * be removed by any change. VACUUM proceeds in a number of passes so
+  * we need to consider how each pass operates. The first pass runs
+  * heap_page_prune(), which can issue XLOG_HEAP2_CLEAN records as it
+  * progresses - these will have a latestRemovedXid on each record.
+  * In many cases this removes all of the tuples to be removed.
+  * Then we look at tuples to be removed, but do not actually remove them
+  * until phase three. However, index records for those rows are removed
+  * in phase two and index blocks do not have MVCC information attached.
+  * So before we can allow removal of *any* index tuples we need to issue
+  * a WAL record indicating what the latestRemovedXid will be at the end
+  * of phase three. This then allows Hot Standby queries to block at the
+  * correct place, i.e. before phase two, rather than during phase three
+  * as we issue more XLOG_HEAP2_CLEAN records. If we need to run multiple
+  * phase two/three because of memory constraints we need to issue multiple
+  * log records also.
+  */
+ static void
+ vacuum_log_cleanup_info(Relation rel, LVRelStats *vacrelstats)
+ {
+   /*
+    * No need to log changes for temp tables, they do not contain
+    * data visible on the standby server.
+    */
+   if (rel->rd_istemp)
+       return;
+
+   (void) log_heap_cleanup_info(rel->rd_node, vacrelstats->latestRemovedXid);
+ }


Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB     http://www.enterprisedb.com