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: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: crash-safe visibility map, take three
Date: 2010-11-30 16:48:08
Message-ID: 4CF52AC8.8080004@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 30.11.2010 18:40, Tom Lane wrote:
> Robert Haas<robertmhaas(at)gmail(dot)com>  writes:
>> That's definitely sucky, but in some ways it would be more complicated
>> if they did, because I don't think all-visible on the master implies
>> all-visible on the standby.
>
> Ouch.  That seems like it could shoot down all these proposals.  There
> definitely isn't any way to make VM crash-safe if there is no WAL-driven
> mechanism for setting the bits.

Note that this is only a problem for *hot* standby. After failover, all 
the tuples that were visible to everyone in the master are also visible 
to all new transactions in the standby.

We dealt with this in 9.0 already, with the "killed" flag in index 
tuples and the PD_ALL_VISIBLE flag in heap scans. We simply don't 
believe them in hot standby mode, and check visibility even if the flag 
is set.

> I guess what we need is a way to delay the application of such a WAL
> record on the slave until it's safe, which means the record also has to
> carry some indication of the youngest XMIN on the page.

Something like that would certainly be nice. With index-only scans, it 
can be a big disappointment if you can't do an index-only scan in hot 
standby.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-11-30 16:49:34
Subject: Re: crash-safe visibility map, take three
Previous:From: Robert HaasDate: 2010-11-30 16:47:40
Subject: Re: crash-safe visibility map, take three

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