Re: Reviewing freeze map code

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Peter Geoghegan <pg(at)heroku(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Subject: Re: Reviewing freeze map code
Date: 2016-05-11 04:54:33
Message-ID: f8a22607-19fb-15a9-0bc9-2aefbc59bef6@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5/10/16 11:42 PM, Jim Nasby wrote:
> On 5/6/16 4:55 PM, Peter Geoghegan wrote:
>> On Fri, May 6, 2016 at 2:49 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>>>> Jeff Janes has done astounding work in these matters. (I don't think
>>>> we credit him enough for that.)
>>>
>>> +many.
>>
>> Agreed. I'm a huge fan of what Jeff has been able to do in this area.
>> I often say so. It would be even better if Jeff's approach to testing
>> was followed as an example by other people, but I wouldn't bet on it
>> ever happening. It requires real persistence and deep understanding to
>> do well.
>
> It takes deep understanding to *design* the tests, not to write them.
> There's a lot of folks out there that will never understand enough to
> design tests meant to expose data corruption but who could easily code
> someone else's design, especially if we provided tools/ways to tweak a
> cluster to make testing easier/faster (such as artificially advancing
> XID/MXID).

Speaking of which, another email in the thread made me realize that
there's a test condition no one has mentioned: verifying we don't lose
tuples after wraparound.

To test this, you'd want a table that's mostly frozen. Ideally, dirty a
single tuple on a bunch of frozen pages, with committed updates,
deletes, and un-committed inserts. Advance XID far enough to get you
close to wrap-around. Do a vacuum, SELECT count(*), advance XID past
wraparound, SELECT count(*) again and you should get the same number.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2016-05-11 05:06:11 Re: Does Type Have = Operator?
Previous Message Ashutosh Sharma 2016-05-11 04:51:30 Re: Perf Benchmarking and regression.