Re: Enabling Checksums - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Enabling Checksums
Date
Msg-id 50A3ED09.6050004@dunslane.net
Whole thread Raw
In response to Re: Enabling Checksums  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Enabling Checksums  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 11/14/2012 02:01 PM, Alvaro Herrera wrote:
> Peter Eisentraut escribió:
>> On 11/11/12 6:59 PM, Andrew Dunstan wrote:
>>> I haven't followed this too closely, but I did wonder several days ago
>>> why this wasn't being made an initdb-time decision.
>> One problem I see with this is that it would make regression testing
>> much more cumbersome.  Basically, to do a proper job, you'd have to run
>> all the tests twice, once against each initdb setting.  Either we
>> automate this, which would mean everyone's tests are now running almost
>> twice as long, or we don't, which would mean that some critical piece of
>> low-level code would likely not get wide testing.
> We already have that problem with the isolation tests regarding
> transaction isolation levels: the tests are only run with whatever is
> the default_transaction_isolation setting, which is read committed in
> all buildfarm installs; so repeatable read and serializable are only
> tested when someone gets around to tweaking an installation manually.  A
> proposal has been floated to fix that, but it needs someone to actually
> implement it.
>
> I wonder if something similar could be used to handle this case as well.
> I also wonder, though, if the existing test frameworks are really the
> best mechanisms to verify block layer functionality.


There is nothing to prevent a buildfarm owner from using different
settings - there is a stanza in the config file that provides for them
to do so in fact.

Maybe a saner thing to do though would be to run the isolation tests two
or three times with different PGOPTIONS settings. Maybe we need two ro
three targets in the isolation test Makefile for that.

Regarding checksums, I can add an option for the initdb that the
buildfarm script runs. We already run different tests for different
encodings. Of course, constant expanding like this won't scale, so we
need to pick the options we want to exrecise carefully.

cheers

andrew




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY
Next
From: Atri Sharma
Date:
Subject: Re: WIP patch for hint bit i/o mitigation