Re: visibility map
От | Heikki Linnakangas |
---|---|
Тема | Re: visibility map |
Дата | |
Msg-id | 4CEB7E65.6000007@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: visibility map (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: visibility map
|
Список | pgsql-hackers |
On 22.11.2010 21:24, Robert Haas wrote: > 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. That's an interesting idea. You pickyback setting the vm bit on the freeze WAL record, on the assumption that you have to write the freeze record anyway. However, if that assumption doesn't hold, because the tuples are deleted before they reach vacuum_freeze_min_age, it's no better than the naive approach of WAL-logging the vm bit set separately. Whether that's acceptable or not, I don't know. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: