Re: Hot Standby (commit fest version - v5)
От | Pavan Deolasee |
---|---|
Тема | Re: Hot Standby (commit fest version - v5) |
Дата | |
Msg-id | 2e78013d0811192221k4458e95bs251931411401f52f@mail.gmail.com обсуждение исходный текст |
Ответ на | Hot Standby (commit fest version - v5) (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Hot Standby (commit fest version - v5)
Re: Hot Standby (commit fest version - v5) |
Список | pgsql-hackers |
<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 />
В списке pgsql-hackers по дате отправления: