From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 8.5 release timetable, again |
Date: | 2009-08-27 16:29:03 |
Message-ID: | 5474.1251390543@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Thu, Aug 27, 2009 at 3:11 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> ... However this is quite haphazard since (a) the regression tests
>> aren't especially designed to exercise all of the WAL logic, and (b)
>> pg_dump might not show the effects of some problems, particularly not
>> corruption in non-system indexes. It would be worth the trouble to
>> create a more specific test methodology.
> What I've been thinking of doing is having the regression suite take a
> backup after initdb and set archive mode on. when the regression suite
> finishes start the backup up and replay all the WAL.
> I'm not sure how to compare the databases since I don't think pg_dump
> actually works here -- a lot of the data is dropped by the end of the
> test.
Yeah, that's another problem with using the existing tests for this
purpose --- a lot of possibly-useful stuff isn't kept around to the end.
And the desire to keep the test modules independent limits the amount of
interaction between them too. I really think we'd need a bespoke set of
tests to get very far with this.
This reminds me that pg_dump/pg_restore is another large pile of code
that receives no formalized testing whatsoever ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2009-08-27 16:30:55 | Re: pretty print viewdefs |
Previous Message | Tom Lane | 2009-08-27 16:17:19 | Re: pretty print viewdefs |