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: Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(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>
Subject: Re: Reviewing freeze map code
Date: 2016-06-08 01:10:05
Message-ID: 120f36f1-755e-29eb-edc0-94db1f1af132@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 6/6/16 3:57 PM, Peter Geoghegan wrote:
> On Mon, Jun 6, 2016 at 11:35 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>>> We need a read-only utility which checks that the system is in a correct
>>> and valid state. There are a few of those which have been built for
>>> different pieces, I believe, and we really should have one for the
>>> visibility map, but I don't think it makes sense to imply in any way
>>> that VACUUM can or should be used for that.
>>
>> Meh. This is vacuum behaviour that *has existed* up to this point. You
>> essentially removed it. Sure, I'm all for adding a verification
>> tool. But that's just pie in the skie at this point. We have a complex,
>> data loss threatening feature, which just about nobody can verify at
>> this point. That's crazy.
>
> FWIW, I agree with the general sentiment. Building a stress-testing
> suite would have been a good idea. In general, testability is a design
> goal that I'd be willing to give up other things for.

Related to that, I suspect it would be helpful if it was possible to
test boundary cases in this kind of critical code by separating the
logic from the underlying implementation. It becomes very hard to verify
the system does the right thing in some of these scenarios, because it's
so difficult to put the system into that state to begin with. Stuff that
depends on burning through a large number of XIDs is an example of that.
(To be clear, I'm talking about unit-test kind of stuff here, not
validating an existing system.)
--
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 Michael Paquier 2016-06-08 01:11:10 Re: Tracking wait event for latches
Previous Message Amit Langote 2016-06-08 00:45:40 Re: Typo in pg_visibility