Skip site navigation (1) Skip section navigation (2)

Re: crash-safe visibility map, take three

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: crash-safe visibility map, take three
Date: 2010-12-01 16:40:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 01.12.2010 18:25, Robert Haas wrote:
> I think we can improve this a bit further by also introducing a
> HEAP_XMIN_FROZEN bit that we set in lieu of overwriting XMIN with
> FrozenXID.  This allows us to freeze tuples aggressively - if we want
> - without losing any forensic information.  We can then modify the
> above algorithm slightly, so that when we observe that a page is all
> visible, we not only set PD_ALL_VISIBLE on the page but also
> HEAP_XMIN_FROZEN on each tuple.

Hmm, actually, if we're willing to believe PD_ALL_VISIBLE in the page 
header over the xmin/xmax on the tuples, we could simply not bother 
doing anti-wraparound vacuums for pages that have the flag set. I'm not 
sure what changes that would require outside heapam.c, as we'd have to 
be careful to not trust the xmin/xmax if the flag was set.

The first update on the page that clears the flag would need to freeze 
all the tuples in that scheme.

   Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2010-12-01 16:40:46
Subject: Re: crash-safe visibility map, take three
Previous:From: Florian PflugDate: 2010-12-01 16:27:14
Subject: Re: FK's to refer to rows in inheritance child

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group