On Tue, 2012-12-04 at 01:03 -0800, Jeff Davis wrote: > > 3. I think we need an explicit test of this feature (as you describe > > above), rather than manual testing. corruptiontester? > > I agree, but I'm not 100% sure how to proceed. I'll look at Kevin's > tests for SSI and see if I can do something similar, but suggestions are > welcome. A few days away, at the earliest.
I looked into this. The SSI tests still use pg_regress to start/stop the server, and make use of a lot more of the pg_regress framework. pg_regress doesn't fit what I need to do, at all. For me, each test involves a fresh initdb, followed by a small data load (at least a few pages). Then, I shut down the server, inject the faults under test, and start the server back up. Then, I count the table and expect an error. Then I throw away the data directory. (I can shortcut some of the initdb and load time by keeping a good copy of the table throughout the whole set of tests and copying it back, but that's just a detail.) So, I could try to write a test framework in C that would be a candidate to include with the main distribution and be run by the buildfarm, but that would be a lot of work. Even then, I couldn't easily abstract away these kinds of tests into text files, unless I invent a language that is suitable for describing disk faults to inject. Or, I could write up a test framework in ruby or python, using the appropriate pg driver, and some not-so-portable shell commands to start and stop the server. Then, I can publish that on this list, and that would at least make it easier to test semi-manually and give greater confidence in pre-commit revisions. Suggestions? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers