On 6/6/16 3:57 PM, Peter Geoghegan wrote:
> On Mon, Jun 6, 2016 at 11:35 AM, Andres Freund <andres@anarazel.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