Re: Hot Standby (commit fest version - v5)

<br /><br /><div class="gmail_quote">On Sat, Nov 1, 2008 at 10:02 PM, Simon Riggs <span dir="ltr"><<a
href="mailto:simon@2ndquadrant.com">simon@2ndquadrant.com</a>></span>wrote:<br /><blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hot Standby patch,
includingall major planned features.<br /><br /><br /></blockquote></div><br />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.<br /><br />This would save us a second
checkof HeapTupleSatisfiesVacuum on the tuples which are just now checked in heap_page_prune(). In addition, the
followingadditional WAL records are then not necessary because heap_page_prune() must have already logged the
latestRemovedXid.<br/><br />+ /*<br />+  * For Hot Standby we need to know the highest transaction id that will<br />+ 
*be removed by any change. VACUUM proceeds in a number of passes so<br />+  * we need to consider how each pass
operates.The first pass runs<br /> +  * heap_page_prune(), which can issue XLOG_HEAP2_CLEAN records as it<br />+  *
progresses- these will have a latestRemovedXid on each record.<br />+  * In many cases this removes all of the tuples
tobe removed.<br />+  * Then we look at tuples to be removed, but do not actually remove them<br /> +  * until phase
three.However, index records for those rows are removed<br />+  * in phase two and index blocks do not have MVCC
informationattached.<br />+  * So before we can allow removal of *any* index tuples we need to issue<br /> +  * a WAL
recordindicating what the latestRemovedXid will be at the end<br />+  * of phase three. This then allows Hot Standby
queriesto block at the<br />+  * correct place, i.e. before phase two, rather than during phase three<br /> +  * as we
issuemore XLOG_HEAP2_CLEAN records. If we need to run multiple<br />+  * phase two/three because of memory constraints
weneed to issue multiple<br />+  * log records also.<br />+  */<br />+ static void<br />+
vacuum_log_cleanup_info(Relationrel, LVRelStats *vacrelstats)<br /> + {<br />+   /*<br />+    * No need to log changes
fortemp tables, they do not contain<br />+    * data visible on the standby server.<br />+    */<br />+   if
(rel->rd_istemp)<br/>+       return;<br />+<br />+   (void) log_heap_cleanup_info(rel->rd_node,
vacrelstats->latestRemovedXid);<br/> + }<br /><br /><br />Thanks,<br />Pavan<br clear="all" /><br />-- <br />Pavan
Deolasee<br/>EnterpriseDB     <a href="http://www.enterprisedb.com">http://www.enterprisedb.com</a><br />