Re: visibility map

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: visibility map
Date: 2010-11-23 08:42:13
Message-ID: 4CEB7E65.6000007@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2010-11-23 09:19:03 Re: Extensions, this time with a patch
Previous Message Dimitri Fontaine 2010-11-23 08:24:46 Re: Extensions, this time with a patch