Re: 8.5 release timetable, again

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

In response to

Browse pgsql-hackers by date

  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