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

Re: Hot standby and GiST page splits (was Re: WIP: Fast GiST index build)

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot standby and GiST page splits (was Re: WIP: Fast GiST index build)
Date: 2011-08-02 11:03:47
Message-ID: 4E37D993.9050808@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 01.08.2011 13:44, Heikki Linnakangas wrote:
> On 01.08.2011 13:13, Simon Riggs wrote:
>> Did you want me to write the patch for 9.0?
>
> I'm looking at it now.

So, in 9.0, we currently leave the rightlink and NSN invalid when 
replaying a page split. To set them correctly, we'd need the old 
rightlink and NSN from the page being split, but the WAL record doesn't 
currently include them. I can see two solutions to this:

1. Add them to the page split WAL record. That's straightforward, but 
breaks WAL format compatibility with older minor versions.

2. Read the old page version, and copy the rightlink and NSN from there. 
Since we're restoring what's basically a full-page image of the page 
after the split, in crash recovery the old contents might be a torn 
page, or a newer version of the page. I believe that's harmless, because 
we only care about the NSN and rightlink in hot standby mode, but it's a 
bit ugly.

If we change the WAL record, we have to make it so that the new version 
can still read the old format, which complicates the implementation a 
bit. Neverthelss, I'm leaning towards option 1.

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

In response to

Responses

pgsql-hackers by date

Next:From: Dean RasheedDate: 2011-08-02 11:28:04
Subject: Re: Compressing the AFTER TRIGGER queue
Previous:From: Ashutosh BapatDate: 2011-08-02 10:53:26
Subject: Re: Doubt about boundParams

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