Re: visibility map
От | 高增琦 |
---|---|
Тема | Re: visibility map |
Дата | |
Msg-id | AANLkTinCZYET70ojyp+y2YXuVO4H4ZNY+_tiZVPoDS70@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: visibility map (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
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 />
В списке pgsql-hackers по дате отправления: