Re: 8.5 release timetable, again - Mailing list pgsql-hackers

From Greg Stark
Subject Re: 8.5 release timetable, again
Date
Msg-id 407d949e0908270838kde9bb7eu7a3d9849095a2152@mail.gmail.com
Whole thread Raw
In response to Re: 8.5 release timetable, again  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 8.5 release timetable, again  (Jaime Casanova <jcasanov@systemguards.com.ec>)
Re: 8.5 release timetable, again  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Aug 27, 2009 at 3:11 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>
> Precisely...
>
> What I'd like to see is some sort of test mechanism for WAL recovery.
> What I've done sometimes in the past (and recently had to fix the tests
> to re-enable) is to kill -9 a backend immediately after running the
> regression tests, let the system replay the WAL for the tests, and then
> take a pg_dump and compare that to the dump gotten after a conventional
> run.  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. But at least that would test that replaying WAL didn't cause any
crashes.

--
greg
http://mit.edu/~gsstark/resume.pdf


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: BUG #4996: postgres.exe memory consumption keeps going up
Next
From: Alvaro Herrera
Date:
Subject: Re: [BUGS] fillfactor hides autovacuum parameters in 8.4.0