Re: visibility map

Can we just log the change of VM in log_heap_clean() for redo?<br />Thanks<br /><br clear="all" />--<br />GaoZengqi<br
/><ahref="mailto:pgf00a@gmail.com">pgf00a@gmail.com</a><br /><a
href="mailto:zengqigao@gmail.com">zengqigao@gmail.com</a><br/><br /><br /><div class="gmail_quote">On Tue, Nov 23, 2010
at3:24 AM, Robert Haas <span dir="ltr"><<a href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>></span>
wrote:<br/><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left:1ex;"> On Mon, Jun 14, 2010 at 1:19 AM, Heikki Linnakangas<br /> <<a
href="mailto:heikki.linnakangas@enterprisedb.com">heikki.linnakangas@enterprisedb.com</a>>wrote:<br /> >> I
*think*that the answer to this parenthesized question is "no".<br /> >> When we vacuum a page, we set the LSN on
boththe heap page and the<br /> >> visibility map page.  Therefore, neither of them can get written to<br />
>>disk until the WAL record is flushed, but they could get flushed in<br /> >> either order.  So the
visibilitymap page could get flushed before the<br /> >> heap page, as the non-parenthesized portion of the
commentindicates.<br /> ><br /> > Right.<br /> ><br /> >> However, at least in theory, it seems like we
couldfix this up during<br /> >> redo.<br /> ><br /> > Setting a bit in the visibility map is currently not
WAL-logged,but yes<br /> > once we add WAL-logging, that's straightforward to fix.<br /><br /> Eh, so.  Suppose -
forthe sake of argument - we do the following:<br /><br /> 1. Allocate an additional infomask(2) bit that means "xmin
isfrozen,<br /> no need to call XidInMVCCSnapshot()".  When we freeze a tuple, we set<br /> this bit in lieu of
overwritingxmin.  Note that freezing pages is<br /> already WAL-logged, so redo is possible.<br /><br /> 2. Modify
VACUUMso that, when the page is observed to be all-visible,<br /> it will freeze all tuples on the page, set
PD_ALL_VISIBLE,and set the<br /> visibility map bit, writing a single XLOG record for the whole<br /> operation
(possiblypiggybacking on XLOG_HEAP2_CLEAN if the same<br /> vacuum already removed tuples; otherwise and/or when no
tupleswere<br /> removed writing XLOG_HEAP2_FREEZE or some new record type).  This<br /> loses no forensic information
becauseof (1).  (If the page is NOT<br /> observed to be all-visible, we freeze individual tuples only when they<br />
hitthe current age thresholds.)<br /><br /> Setting the visibility map bit is now crash-safe.<br /><br /> Please poke
holes.<br/><br /> --<br /> Robert Haas<br /> EnterpriseDB: <a href="http://www.enterprisedb.com"
target="_blank">http://www.enterprisedb.com</a><br/> The Enterprise PostgreSQL Company<br /><font color="#888888"><br
/>--<br /> Sent via pgsql-hackers mailing list (<a
href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br/> To make changes to your
subscription:<br/><a href="http://www.postgresql.org/mailpref/pgsql-hackers"
target="_blank">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/></font></blockquote></div><br />