Can we just log the change of VM in log_heap_clean() for redo? Thanks -- GaoZengqi pgf...@gmail.com zengqi...@gmail.com
On Tue, Nov 23, 2010 at 3:24 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Jun 14, 2010 at 1:19 AM, Heikki Linnakangas > <heikki.linnakan...@enterprisedb.com> wrote: > >> I *think* that the answer to this parenthesized question is "no". > >> When we vacuum a page, we set the LSN on both the heap page and the > >> visibility map page. Therefore, neither of them can get written to > >> disk until the WAL record is flushed, but they could get flushed in > >> either order. So the visibility map page could get flushed before the > >> heap page, as the non-parenthesized portion of the comment indicates. > > > > Right. > > > >> However, at least in theory, it seems like we could fix this up during > >> redo. > > > > Setting a bit in the visibility map is currently not WAL-logged, but yes > > once we add WAL-logging, that's straightforward to fix. > > Eh, so. Suppose - for the sake of argument - we do the following: > > 1. Allocate an additional infomask(2) bit that means "xmin is frozen, > no need to call XidInMVCCSnapshot()". When we freeze a tuple, we set > this bit in lieu of overwriting xmin. Note that freezing pages is > already WAL-logged, so redo is possible. > > 2. Modify VACUUM so that, when the page is observed to be all-visible, > it will freeze all tuples on the page, set PD_ALL_VISIBLE, and set the > visibility map bit, writing a single XLOG record for the whole > operation (possibly piggybacking on XLOG_HEAP2_CLEAN if the same > vacuum already removed tuples; otherwise and/or when no tuples were > removed writing XLOG_HEAP2_FREEZE or some new record type). This > loses no forensic information because of (1). (If the page is NOT > observed to be all-visible, we freeze individual tuples only when they > hit the current age thresholds.) > > Setting the visibility map bit is now crash-safe. > > Please poke holes. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
