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.



Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to